Ну что ж, пришло время поговорить о безопасности. Но прежде чем мы приступим, я немного вернусь назад. В самой первой статье я говорил о том, что информацию можно вернуть вызываемому приложению как объект. Как вернуть информацию в виде массива мы уже разобрались. Массив – это просто данные, которыми удобно манипулировать.

Если вы хотите предоставить удалённым разработчикам объект, который, в т.ч., может обращаться к Host 1 для вызова API, достаточно просто создать этот объект на стороне API-сервера и вернуть вызываемому приложению вместе с классом (и всеми родительскими классами), который является типом этого объекта. Сделать это очень просто. Достаточно прочитать файл, в котором хранится определение класса, с помощью стандартных функций типа fopen и вернуть в качестве строки. На стороне приложения (Host 2) эту строку нужно сохранить в локальный файл (фактически получим копию файла на API-сервере) и подключить этот файл с помощью incude.

О том, как передаются сериализованные объекты, можно подробнее прочитать в справке PHP.
Теперь вплотную займёмся безопасностью. Условно, меры, которые мы можем предпринять, можно разделить на следующие пункты:

1. Авторизация с уровнями доступа.
2. Фильтрация запроса.
3. Использование защищённого соединения.
4. Использование различных трюков.

(more…)

Всем привет. Итак, пришло время создать классы Gateway и Connector и посмотреть на наш API в деле. Для этого нам понадобится доступ к удалённому хосту или виртуальные хосты Apache. Я буду использовать удалённый хост.

Итак, создайте на удалённом хосте структуру базы, как это было описано во второй части статьи. Теперь нужно написать класс Gateway, который реализует протокол передачи данных. Как я уже говорил, будем исходить из объективной простоты, а именно – наши данные будут передаваться в виде сериализованного и закодированного POST запроса. Хотя, никто не мешает разработать свой протокол и потратить на это пару килобаксов вашего заказчика.
(more…)

Как я и обещал, сегодня мы допилим классы api_executor и api_functions. Для начала посмотрим на класс api_functions и интерфейс api_functions_itrfc. Интерфейс api_functions_itrfc теперь выглядит так: (more…)

Введение

Всем привет. Сегодня я начну цикл статей, посвящённых созданию API.

Сразу, несколько ответов на ваши невысказанные вопросы:

1. Цикл, потому что материал достаточно объёмный и серьёзный. В одну статью не вместится.
2. API (application programming interface, в переводе с буржуйского – интерфейс программирования приложений) используется в том случае, если необходимо предоставить сторонним разработчикам часть низкоуровневого функционала некоторой системы.
3. Класс задач, в которых используется API, разнообразен. Вот несколько примеров: вы являетесь владельцем базы данных всех жителей страны и хотите предоставить возможность различным компаниям через их корпоративные приложения пользоваться вашей базой. В этом случае, вам необходим API, т.к. просто продать базу данных экономически невыгодно и несёт в себе риск по утечке информации. Другой пример: у вас есть некоторая мультифункциональая система и вы хотите предоставить её часть для эволюции другим программистам. Так делает, например, Vkontakte. (more…)