Отправляет email-рассылки с помощью сервиса Sendsay

Веб-разработка: пособие начинающим

Рассылка закрыта

При закрытии подписчики были переданы в рассылку "Левитас: Почему Ваш бизнес-сайт не работает?" на которую и рекомендуем вам подписаться.

Вы можете найти рассылки сходной тематики в Каталоге рассылок.

←   Февраль 2011   →
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Автор
Александр Левитас

Статистика

10.726 подписчиков
-23 за неделю
←   Все выпуски   →

Веб-разработка? Это просто! Создаем собственный API


Создаем собственный API

Введение

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

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

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

Краткое содержание цикла статей

Разбираясь с вопросом, к окончанию цикла статей мы пройдём следующие шаги

  1. Спроектируем свой полноценный API для взаимодействия двух приложений
  2. Воплотим проектное решение в коде
  3. Обсудим вопросы безопасности
  4. Спроектируем и создадим шлюз для стороннего приложения, через который оно сможет использовать наш API
  5. Протестируем то, что получилось

Инструменты

Для работы я буду использовать

  1. PHP 5.2.5
  2. MySQL 5.0.51
  3. Apache 2.0
  4. Firefox 3.6.10
  5. cURL 7.16
  6. Win32 XP SP2

Вы можете без проблем использовать более новые версии.

Кроме того, для работы над проектом понадобится настройка виртуальных хостов Apache или доступ к удалённому серверу. О настройке виртуальных хостов Apache можно почитать тут http://www.asweb.ru/articles/web/virtualhosts

Об инсталляции библиотеки cURL можно почитать на официальном сайте http://curl.haxx.se/

Вместо cURL можно использовать обычное сокетное соединение, но для простоты я всё таки буду использовать cURL.

Постановка задачи

Итак, наша конечная цель получить работающий неуниверсальный API для демонстрации тестовых примеров, разработать тестовое приложение, которое будет использовать наш API и разработать свой шлюз, который обеспечит передачу запросов от приложения к API. Мы не ставим целью разработку коммерческого класса, но только лишь демонстрационного. Что будет делать наш API? Мы создадим MySQL таблицу и предоставим возможность удалённому приложению манипулировать с данными из этой таблицы. Поскольку в нашем модуле безопасности будет существовать система привилегий, мы будем обеспечивать 3 уровня доступа - select, select + insert, select + insert + delete.

Проектируем API

Проектировать будем схематично, т.к. повторюсь - наша цель не коммерческий продукт, а понимание, как это делается.

Общая схема того, что должно получиться, будет следующая (см. рис. "api model.jpg"):

api model

Host 1 - это сервер, на котором работает веб приложение (Application 1), которое предоставляет API сторонним клиентам. API Handler - это некоторая программная структура, которая и реализует API. API Handler общается с бизнес-логикой основного приложения (Black Box) через запрос (Request) и возвращает через шлюз (Gateway) ответ бизнес-логики (Response).

Host 2 - это клиент, на котором работает веб-приложение (Application 2), которое инициирует запрос к Host 1::Application 1 посредством программного интерфейса. Для этого Application 2 использует класс Connector, основная задача которого обеспечить отправку правильного запроса, содержащего всю необходимую информацию, т.е. вызов API в правильном формате. Многочисленные стрелки в Application 2 моделируют использование API.

Понятно, что приложение Application 1 - уникально, а приложений типа Application 2 может быть сколь угодно много.

Спроектируем API Handler.

API Handler должен состоять из следующих частей

  1. Модуль безопасности. Мы не можем допустить утечки информации или краха системы.
  2. Модуль, предоставляющий API
  3. Обработчик API (собственно, сам Handler. Назовём его Executor чтобы не путаться)
  4. Должен иметь возможность общаться с Black Box (Request/Response)
  5. Должен быть расширяемым (возможность быстро добавить и/или удалить некоторые API функции)
  6. Лог. Все подсистемы API Handler имеют возможность сохранять инфо в лог.

В этом месте встаёт вопрос, какие именно сущности будет предоставлять API. Можно построить API, который будет предоставлять клиенту набор функций. Можно предоставить клиенту набор объектов. Мы рассмотрим оба варианта.

Модуль безопасности должен:

  1. Обеспечивать авторизацию. API должны пользоваться только те хосты, которым мы это разрешили.
  2. Фильтровать данные
  3. Фильтровать запросы
  4. Реализовывать систему привелегий.
  5. Быть расширяемым. Возможно, со временем мы введём новые требования к защите.

Модуль, предоставляющий API, должен быть:

  1. Расширяемым
  2. Работать с данными однородного вида

Обработчик API должен:

  1. Иметь лимит на выполнение запросов от удалённого хоста.

Теперь разберём Gateway.

Gateway должен соответствовать следующим параметрам:

  1. Обеспечивать работу унифицированного протокола передачи данных.
  2. Подготовить данные для работы API Handler
  3. Вернуть ответ API Handler вызывающему хосту.

Что касается Connector, то тут всё будет гораздо проще.

Мы будем использовать cURL для связи с первым хостом. Connector никак не будет обрабатывать получаемые запросы от приложения 2. Его задача просто обеспечить отправку запроса к хосту 1 и возврат ответа в приложение 2. Приложение 2 далее будет решать, насколько верный ответ получен.

Итак, Connector обладает следующими параметрами:

  1. Отправляет запрос, в формате, который требует Gateway. Для простоты, Gateway будет обрабатывать стандартный POST запрос.
  2. Получает ответ от Gateway и передаёт его приложению 2.

Резюме

В этой статье мы разобрались что же такое API и зачем он нужен.

Мы определили задачу и разобрались с минимальным разумным набором компонентов API.

Мы схематично спроектировали будущий API Handler некоторой системы. И готовы преступить к кодированию.

В следующей статье мы сделаем первый шаг к имплементации реально работающего API, а именно, - мы реализуем класс API Executor в первом приближении. В будущих статьях мы постепенно нарастим этот функционал до приемлемого уровня и займёмся реализацией остальных классов.

Всем удачи.
В избранное