Поступила задача – создать API для сайта scribbler.ru, которое позволило бы сторонним разработчикам работать с ресурсами сайта, писать приложения как внутри, в виде swf файла, так и находящиеся вне сайта, допустим десктопное приложение, которое может получать/отправлять почту пользователям сайта.
Всем известно, что популярные российские проекты (vkontakte.ru, mail.ru и какие-либо другие) имеют свой API. Для примера я начал было их осваивать и смотреть, как же они реализованы, и знаете что, каждый сайт пишет API так, как ему вздумается (как разработчики считают правильным), т.е. API mail.ru и vkontakte.ru сильно разнятся в своих архитектурах, грубо говоря они не схожи, что, я думаю, усложняет жизнь разработчикам, сперва пишем свои классы, работающие с API, под vkontake, потом пишем свои классы под mail.ru и т.д.
Возник вопрос: «А как же решили эту задачу «забугорные» сайты?»
Идем на twitter.com, заходим в раздел «API», смотрим, читаем и видим «The Twitter API attempts to conform to the design principles of Representational State Transfer (REST)».
Идем на facebook.com, заходим в раздел «Разработчики->documentation» и снова видим «The API uses a REST-like interface».
Да блин! Что же такое этот REST?
И вот оно! REST описывает архитектуру парадигмы для web—приложений, которые запрашивают и манипулируют web—ресурсами, используя стандартные HTTP методы GET, POST, PUT и DELETE.
Все мы знаем, что такое SOAP сервис, так REST это нечто похожее, только проще ;).
Благодаря REST мы можем обращаться к методам объектов нашего сайта, передавая параметры методами GET и POST и получая в ответ от сервера XML. Т.е., допустим, нам нужно получить информацию о пользователе, тогда мы идем по адресу .../api/user.getInfo?userId=10, в ответ нам придет XML с информацией о нем, в этом адресе наглядно видно, что мы обращаемся к объекту user и выполняем его метод getInfo, входным параметром будет userId=10, в PHP это выглядело бы так $user->getInfo(10).
Просто? Удобно? Еще как!
Ладно, хватит уже глагольствовать, пора переходить к принципу реализации, представляя, что сайт реализован на MVC архитектуре.
У API должны быть свои объекты, не стоит вызывать методы объектов, которые используются внутри сайта, в целях безопасности, думаю, это все понимают.
Итак, представим себе, что объекты API хранятся в своей папочке внутри проекта, и какой-либо разработчик обращается по адресу .../api/user.getInfo, тут врубается apiController, начинает проверять, существует ли объект user с методом getInfo, если нет, то возвращает XML со статусом ошибки, если да, то создает этот объект, вызывает нужный метод, конвертит возвращенные данные в XML и выводит в view.
Пошагово все это будет выглядеть так:
Таким образом, мы получаем API по архитектуре похожее на API twitter и facebook, которое структурировано, легко, а главное удобно разрабатывать и позволяет разрабочтикам сторонних приложений не ломать голову над курением чтением документации, и легко портировать приложения под ваши проекты.
В следующий раз продолжим беседу об OAuth авторизации, которая позволяет не вводить логин и пароль пользователя, для использования API.
Итак, теперь, сайт scribbler.ru имеет свой API, и если есть желающие опробовать его в действии, то «Welcome!», объективную критику и ценные пожелания расцениваем на отличненько!
Документацию по API можно прочитать здесь scribbler.ru/developers.
P.S. Старался писать как можно понятнее, история про разработку придумана и основана на реальных событиях ;)
Всем известно, что популярные российские проекты (vkontakte.ru, mail.ru и какие-либо другие) имеют свой API. Для примера я начал было их осваивать и смотреть, как же они реализованы, и знаете что, каждый сайт пишет API так, как ему вздумается (как разработчики считают правильным), т.е. API mail.ru и vkontakte.ru сильно разнятся в своих архитектурах, грубо говоря они не схожи, что, я думаю, усложняет жизнь разработчикам, сперва пишем свои классы, работающие с API, под vkontake, потом пишем свои классы под mail.ru и т.д.
Возник вопрос: «А как же решили эту задачу «забугорные» сайты?»
Идем на twitter.com, заходим в раздел «API», смотрим, читаем и видим «The Twitter API attempts to conform to the design principles of Representational State Transfer (REST)».
Идем на facebook.com, заходим в раздел «Разработчики->documentation» и снова видим «The API uses a REST-like interface».
Да блин! Что же такое этот REST?
И вот оно! REST описывает архитектуру парадигмы для web—приложений, которые запрашивают и манипулируют web—ресурсами, используя стандартные HTTP методы GET, POST, PUT и DELETE.
Все мы знаем, что такое SOAP сервис, так REST это нечто похожее, только проще ;).
Благодаря REST мы можем обращаться к методам объектов нашего сайта, передавая параметры методами GET и POST и получая в ответ от сервера XML. Т.е., допустим, нам нужно получить информацию о пользователе, тогда мы идем по адресу .../api/user.getInfo?userId=10, в ответ нам придет XML с информацией о нем, в этом адресе наглядно видно, что мы обращаемся к объекту user и выполняем его метод getInfo, входным параметром будет userId=10, в PHP это выглядело бы так $user->getInfo(10).
Просто? Удобно? Еще как!
Ладно, хватит уже глагольствовать, пора переходить к принципу реализации, представляя, что сайт реализован на MVC архитектуре.
У API должны быть свои объекты, не стоит вызывать методы объектов, которые используются внутри сайта, в целях безопасности, думаю, это все понимают.
Итак, представим себе, что объекты API хранятся в своей папочке внутри проекта, и какой-либо разработчик обращается по адресу .../api/user.getInfo, тут врубается apiController, начинает проверять, существует ли объект user с методом getInfo, если нет, то возвращает XML со статусом ошибки, если да, то создает этот объект, вызывает нужный метод, конвертит возвращенные данные в XML и выводит в view.
Пошагово все это будет выглядеть так:
Таким образом, мы получаем API по архитектуре похожее на API twitter и facebook, которое структурировано, легко, а главное удобно разрабатывать и позволяет разрабочтикам сторонних приложений не ломать голову над курением чтением документации, и легко портировать приложения под ваши проекты.
В следующий раз продолжим беседу об OAuth авторизации, которая позволяет не вводить логин и пароль пользователя, для использования API.
Итак, теперь, сайт scribbler.ru имеет свой API, и если есть желающие опробовать его в действии, то «Welcome!», объективную критику и ценные пожелания расцениваем на отличненько!
Документацию по API можно прочитать здесь scribbler.ru/developers.
P.S. Старался писать как можно понятнее, история про разработку придумана и основана на реальных событиях ;)
