Что такое REST API?

TCP

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

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

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

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

Суть в том, что rest не о вызове функций, он об операциях над ресурсами. В этом наверное и основное отличие от всяких SOAP.

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

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

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

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

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

То есть рест это исключительно работа с ресурсами?

А если взять например вот это http://api.mail.ru/docs/guides/restapi/

mail.ru как ни как крупный ресурс, в их версии рест апи ничего про ресурсы нету, просто набор функций.

Ну, вообщем-то, можно так сказать, да.

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

Думаю, проще будет понять на примере. Скажем, у нас есть какой-нибудь сервис анонимных объявлений и клиент к нему. Сервер предоставляет рест апи в виде привязанных к урлам и 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 методом. Вот, собственно, и весь рест, если не углубляться в идеалогию и детали реализации.

Именно, только для POST, PUT не /ad, а /ads как и для GET.

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

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

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

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

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

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

Главный момент - вопрос состояний...

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

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

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

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

Он передается в теле запроса. Если формат json, то внутри гет мы передаем { city: City, someparam: 1, ...}

В query param или path param.

grouzen, tailgunner, согласен с замечаниями.

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

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

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

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

Если формат json, то внутри гет мы передаем

Ох, упаси оператива такие передачи!

Причем тут оператива?

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

Человеческая. Которая эту дикость в браузерной строке видит.

Они тут вообще не о браузерах говорят :)

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

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