> Никто не мешает реализовать RPC-интерфейсы поверх HTTP, получая его семантику там, где она нужна. Более того, большинство из так называемых «RESTful API» именно так и делают — они представляют собой ориентированный на данные CRUD RPC, а термин REST используется сугубо как популярный баззворд.
Абсолютно ничто не мешает, кроме того факта, что HTTP как-то знает и трактует большое количество ПО в мире, а под ваш протокол придётся написать кастомные имплементации.
> Центральная идея REST — Uniform Interface, неотъемлемой частью которого является т. н. HATEOAS: REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state. Филдинг подтверждает это в том числе в своем посте REST APIs must be hypertext-driven
Этот пост Фьелдинг написал спустя восемь лет после своего дисера — когда REST уже давно отправился в свободное плавание как концепция. Если б Фьелдинг что-то подобное написал в 2000, недалеко бы его дисер разошёлся.
REST по Фьелдингу-2000 небесспорная, но стройная концепция. REST по Фьелдингу-2008 попросту не существует.
RPC тяжело кэшировать и масштабировать. Чтобы раскидать по шардам — надо прочитать ответ и вычленить из него данные. Чтобы промежуточная прокси узнала, можно ли положить ответ в кэш — аналогично. А уж идемпотентна ли операция из сигнатуры запроса вообще никак не узнать.
Идея REST заключается строго в следующем: есть метаинформация запроса (http-коды, методы, URL, заголовки), давайте построим систему, в которой все агенты умеют их понимать и трактовать. Т.е. например если метод GET — значит, запрос немодифицирующий, можно его префетчить, как-то так.
Абсолютно ничего не мешает ровно те же данные и в заголовки записать.
Разница между тем, в какую часть ответа писать данные, заключается только в том, о чем я написал: манипулировать заголовками на уровне прокси гораздо проще и удобнее, нежели телом ответа, в т.ч. и логировать проще.
Строго говоря не будет — состояние ресурса-то не изменилось.
А вообще в таких ситуациях лучше передавать с клиента ключ идемпотентности или последнюю известную ревизию/ETag ресурса. Тогда сервер сможет сделать вывод: это клиент повторил запрос, и можно ответить 200; или на клиенте какая-то ошибка в коде, и надо отвечать 4хх.
Большинство примеров API в общих разделах будут даны в виде JSON-over-HTTP-эндпойтов. Это некоторая условность, которая помогает описать концепции, как нам кажется, максимально понятно. Вместо `GET /v1/orders` вполне может быть вызов метода `orders.get()`, локальный или удалённый; вместо JSON может быть любой другой формат данных. Смысл утверждений от этого не меняется.
Абсолютно ничто не мешает, кроме того факта, что HTTP как-то знает и трактует большое количество ПО в мире, а под ваш протокол придётся написать кастомные имплементации.
> Центральная идея REST — Uniform Interface, неотъемлемой частью которого является т. н. HATEOAS: REST is defined by four interface constraints: identification of resources; manipulation of resources through representations; self-descriptive messages; and, hypermedia as the engine of application state. Филдинг подтверждает это в том числе в своем посте REST APIs must be hypertext-driven
Этот пост Фьелдинг написал спустя восемь лет после своего дисера — когда REST уже давно отправился в свободное плавание как концепция. Если б Фьелдинг что-то подобное написал в 2000, недалеко бы его дисер разошёлся.
REST по Фьелдингу-2000 небесспорная, но стройная концепция. REST по Фьелдингу-2008 попросту не существует.
Идея REST заключается строго в следующем: есть метаинформация запроса (http-коды, методы, URL, заголовки), давайте построим систему, в которой все агенты умеют их понимать и трактовать. Т.е. например если метод GET — значит, запрос немодифицирующий, можно его префетчить, как-то так.
Разница между тем, в какую часть ответа писать данные, заключается только в том, о чем я написал: манипулировать заголовками на уровне прокси гораздо проще и удобнее, нежели телом ответа, в т.ч. и логировать проще.
На самом деле я порефакторил HTML-версию, она должна теперь нормально с мобильных читаться.
Только что в ландшафт перевернуть.
А вообще в таких ситуациях лучше передавать с клиента ключ идемпотентности или последнюю известную ревизию/ETag ресурса. Тогда сервер сможет сделать вывод: это клиент повторил запрос, и можно ответить 200; или на клиенте какая-то ошибка в коде, и надо отвечать 4хх.
github.com/twirl/The-API-Book#current-state-and-the-roadmap