построение правильного API

[Ragazzo]

Кто как делает API для работы сторонних приложений со своим?также интересует например взаимодействие модулей между собой, т.к. тоже ведь через API какое-либо. Киньте пару статей по правильному построению API и т п, просто не знаю с чего именно тут начать.

 

[флоппик]

Правильно начать — с ТЗ и документации.

 

[Ragazzo]

флоппик
Ок. а можешь кинуть ссылки или примеры того как делать API? нашел давно как-то на хабре такое конечно не совсем то что мне надо, но тут хотя бы рассказывается что за чем делать.

 

[флоппик]

Блин, я щас попробую что нить тебе собрать, не нарушая NDA

 

[Absinthe]

Мне кажется, тут можно просто дать ссылку: http://en.wikipedia.org/wiki/Representational_state_transfer#Constraints

Я сначала делаю апи, а потом уже к ней пишу ООП-обертки с разными исключениями, структурами данных и т.д.
Но изначальные апи просто получают запрос и отдают json.

 

[Absinthe]

Ragazzo это ты на жабе пишешь?

Для API-клиента использую org.apache.http.impl.client.DefaultHttpClient и org.json.simple.JSONObject.

 

[Ragazzo]

Absinthe

Ragazzo это ты на жабе пишешь?

не, не на ява. на Yii просто возникла необходимость в API для приложения. там есть стандартные SOAP, вот я и хотел немного не REST а именно через SOAP и WDSL сделать, но походу можно сделать и так как ты описал.

Я сначала делаю апи, а потом уже к ней пишу ООП-обертки с разными исключениями, структурами данных и т.д.

Т.е. ты сначала REST API делаешь как я понял или API для взаимодействия между модулями тоже?

 

[Absinthe]

Да, я делаю REST на сервере, а потом делаю уже к ним удобную клиентскую оболочку, которая внутри себя скроет все HTTP-запросы и т.д.

Точнее поэтапно, но сначала сервер всегда, а только потом клиента.
Если времени не хватает, то зачастую апи клиента получаются не такими объектными, как хотелось бы И тогда оттуда торчат не объекты, а словари.

 

[Ragazzo]

Absinthe
Ок, понял, спасибо

 

[AmdY]

Тебе нужно умное апи или просто методы доступа к данным, а расчёты можно делать уже на клиенте?

 

[Ragazzo]

AmdY
Скорее просто методы доступа к данным, там в основном будет нужно реализовать обычный CRUD для объектов модулей + некий доп. функционал (работа не с объектами модулей), поэтому я и склонялся больше к SOAP, но впринципе пока время терпит хочу попробовать сделать и REST. Т.е. в основном это будут простые запросы к приложению и все, без каких-либо наворотов.

 

[Yoskaldyr]

AmdY
Скорее просто методы доступа к данным ... но впринципе пока время терпит хочу попробовать сделать и REST.

Если нужен только быстрый доступ к данным, и не пугает писать или большие конфиги или на чем-то другом отличном от PHP можно попробовать http://openresty.org/
Набор модулей для Nginx-а для прямого доступа к различным базам данным + возможность добавления логики на lua. Работает очень быстро. Иногда полезно для исключения пхп в очень узких местах (стабильная и обкатанная вещь, в продакшене уже давно, пишут китайские товарищи для TaoBao, если кто не в курсе такой большой китайский eBay).

Т.е. в основном это будут простые запросы к приложению и все, без каких-либо наворотов.

Но если вдруг логики будет много, то смысла в такой прослойке не будет, т.к. дублировать код на 2-х языках, а учитывая что луа это не пхп и библиотек готовых маловато, то неблагодарное это занятие. В таких случаях просто все писать на пхп.

 

[Ragazzo]

Yoskaldyr
Да, в этом случае скорей всего OpenResty не подойдет, но все равно спасибо, возьму на заметку эту штуку

 

[Yoskaldyr]

Ragazzo
Она очень подходит когда есть какая-то публичная общедоступная информация, которую удобно отдавать клиенту ajax-ом в виде json-а, напрмиер тултипы какие, информация о товаре и т.п. Когда в итоге все сводится к 1-2 запросам к бд и отдаче пользователю в виде json-а ответа полученного из базы. В таких случаях использование пхп может довольно излишним и этот набор модулей для nginx-а подходит идеально, Но конечно стоит заморачиваться когда таких ajax-запросов значительно больше обычных и они создают основную нагрузку на пхп бекэнд