LINUX.ORG.RU

Что такое REST API?


0

1

В общем почитал разное на эту тему... ничего по факту ни где не написано.
Ну с выдачей результата после запроса все в принципе придерживаются или xml или json.
А вот с формированием запроса, если посмотреть реализации от разных контор, целый зоопарк. Кто то принимает параметры запроса просто как get запрос, кто то те же параметры но строго через post, кто то принимает параметры через json в теле пост запроса, некоторые упарываются ооп и формируют строки запроса относительно /class/method/param1/param2/param3 ....
Куча философии на тему GET, POST, PUT, DELETE. Зачем это вообще? Почему просто не передавать их как и остальные параметры ведь на практике все равно сводится к этому для поддержки серверов не поддерживающих PUT и DELETE?
Кто то говорит что рест апи это исключительно сервер-сервер, а для клиент-сервер нужно js api.

Есть вообще какие нибудь общепринятые стандарты?

★★★★★

Если кратко, то суть в том, чтобы не городить велосипед каждый раз, а придерживаться одной философии - данные твоего приложения, отображаются в иерархическую древовидную структуру, над которой можно выполнять CRUD операции. Дальше можно углубиться в такие вещи как мета информация(самоописание) каждого узла и тд. Вообще где-то был RFC на эту тему, там все хорошо разжевано.

grouzen ★★ ()

Есть вообще какие нибудь общепринятые стандарты?

XML-RPC и пародия на него в виде JSON-RPC. Как раз как ты хочешь. Довольно старые, с авторитетными спеками. Но я не уверен, признают ли их любители REST.

const86 ★★★★★ ()
Ответ на: комментарий от grouzen

А если речь не о данных, а о вызове функций которые принимают разные параметры и возвращают результат вычисления?

TDrive ★★★★★ ()
Ответ на: комментарий от const86

Но я не уверен, признают ли их любители REST.

Нет, конечно. Филдинг сказал, что REST - это не RPC.

tailgunner ★★★★★ ()
Ответ на: комментарий от const86

Как раз как ты хочешь.

Я пока ни как не хочу.) Пытаюсь разобраться в терминологии.

Почитал про XML-RPC, неожиданно его тоже называют рест апи, по крайней мере JSON-RPC точно видел.

TDrive ★★★★★ ()
Ответ на: комментарий от TDrive

Ну что ты хочешь от mail.ru? Посмотри лучше на какой-нибудь twitter или github.

grouzen ★★ ()

Думаю, проще будет понять на примере. Скажем, у нас есть какой-нибудь сервис анонимных объявлений и клиент к нему. Сервер предоставляет рест апи в виде привязанных к урлам и http методам собственные методы. Скажем, клиенту нужно получить все объявления в конкретном городе. Он отправляет

GET http://service.com/ads

и в ответ получает json или xml с описанием объявлений. Далее клиент хочет узнать подробную информацию о конкретном объявлении, айдишник которого он получил в предыдущем ответе. Он отправляет
GET http://service.com/ad/{id}

Если клиент хочет создать объявление, он отправляет уже
POST http://service.com/ad
а в теле запроса информацию по объявлению. Если изменить, то
PUT http://service.com/ad/{id}
а в теле запроса обновленную информацию. Если удалить, то то же самое с DELETE методом. Вот, собственно, и весь рест, если не углубляться в идеалогию и детали реализации.

f1xmAn ★★★★★ ()
Ответ на: комментарий от f1xmAn

Скажем, клиенту нужно получить все объявления в конкретном городе. Он отправляет
GET http://service.com/ads
и в ответ получает json или xml с описанием объявлений.

Как в данном случае указывается нужный город?

TDrive ★★★★★ ()
Ответ на: комментарий от f1xmAn

Еще важно то, что идентификаторы созданных ресурсов возвращаются в документах-ответах. Т.е. может быть, что для изменения объявления нужно будет делать:

PUT http://service.com/ads/ads-for-whatever-topic/{id}

Причем URL может меняться без предупреждения пользователей API.

tailgunner ★★★★★ ()

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

swwwfactory ★★ ()
Ответ на: комментарий от TDrive

Можно по подробнее?

В общем считается в идеале, что каждый запрос хранит в себе и только в себе все необходимое для обработки этого запроса. Никаких хранений состояний (промежуточных) на серверах... Это идеал. Сервер ничего не знает о клиентах, пока они не обратятся с запросом. На практике так не всегда можно реализовать и/или реализация будет слишком простой/дубоватой. Фактически сервер пытается снять с себя ответственность за хранение состояний и повесть это на клиентов... Зачастую это удается и сверх разумной меры... Но позволяет сильно упростить обработку и сэкономить ресурсы сервера...

swwwfactory ★★ ()

А зачем париться по поводу этих дурацких названий? Просто пиши свои сервисы — и пофиг, как это называется!

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от grouzen

К сожалению (или даже к счастью), гет не имеет тела, поэтому дополнительные параметры нужно передавать в урле. :)

f1xmAn ★★★★★ ()

некоторые упарываются ооп и формируют строки запроса относительно /class/method/param1/param2/param3 ....

это другое. Просто многие фреймворки имеют свой движок, который при дерганьи подобных урлов, осуществляет роутинг этих параметров до методов конкретного класса и вызов методов.

Например http://pecan.readthedocs.org/en/latest/rest.html#rest

n_play ()
Ответ на: комментарий от f1xmAn

Вообще говоря имеет, но предпочтительно конечно передавать в строке запроса

grouzen ★★ ()

А вот с формированием запроса, если посмотреть реализации от разных контор, целый зоопарк.

REST это парадигма/концепция построения архитектуры системы для предоставления удалённых ресурсов. Краеугольные углы - простота протокола и отсутствие сессий/хранения состояния. Выгоды простота, легкая изменяемость, простая масштабируемость. Минусы не все можно этой парадигмой просто обнять - очень часть с течением времени архитектура теряет простоту и переходит в состояние «глаза б мои не видели»; частое усложнение клиента.

vtVitus ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.