REST: запрос в качестве подмножества ответа

Question

Я сталкивался с многочисленными JSON через HTTP API, которые, как предполагалось, были RESTful, но я не уверен, придерживается ли следующий дизайн принципов REST - Модель запроса используется в качестве подмножества модели Response.

Например, POST / рейс / запрос Запрос:

{ 
   "flight_no":"2384B",
   "departure_time":78163918839123,
   "arrival_time":78163918889382,
   ...
}

Ответ:

{
  "request" : 
     { 
       "flight_no":"2384B",
       "departure_time": 78163918839123,
       "arrival_time": 78163918889382,
       ...
     }
  "status" : "ON TIME"
  "last_updated" :  7816391884313,
  ...
}

Если мы проанализируем это с точки зрения Ричардсон Модель зрелости , я думаю, что она не подходит для уровня 1, потому что нет четкого определения ресурса. Если мы будем называть «Запрос» в качестве ресурса здесь, ответ не должен иметь результат на запрос, такой как status, last_updated, et c. Как правило, он должен ответить с помощью query_id (например, 123), который можно передать второй конечной точке GET /flight/123/status. Хотя этот подход более соответствует принципам REST (поправьте меня, если я ошибаюсь), разработчики, как правило, избегают его просто потому, что одно и то же поведение можно легко сжать в одной конечной точке, а не в двух. У меня вопрос: есть ли последствия игнорированию принципов REST в таких ситуациях, когда проще использовать ярлыки?

Answer 1

Я думаю, что ваше текущее понимание подозрительно.

Использование POST для запроса представления ресурса не является RESTful, потому что у нас есть GET, который более подходит.

Неудобно использовать POST для поиска информации, когда эта информация соответствует потенциальному ресурсу, потому что такое использование предотвращает безопасное повторное использование и сетевой эффект наличия URI. - Fielding, 2008

Больше идиоматических c запросов будет больше похоже на

GET /flights?flight_no=2384B

или даже

GET /flights?flight_no=2384B&departure_time=78163918839123&arrival_time=78163918889382

В этих случаях никто не удивился бы тому, что те же «параметры», которые используются в идентификаторе, также повторяются в представлении ресурса.

Учитывая, что клиенту назначена семантика POST, существует абсолютно нет ничего плохого в ответе, который выглядит следующим образом:

200 OK
Content-Location: https://example.org/flights?flight_no=2384B&departure_time=78163918839123&arrival_time=78163918889382

В этом случае наличие параметров в теле ответа также будет вполне нормальным (так же, как если бы клиент использовал GET для этого ресурса). напрямую).

есть ли последствия игнорированию принципов REST в ситуациях, подобных этим, где проще использовать ярлыки?

Если вы ослабите архитектурные ограничения REST , то вы больше не можете ожидать, что соответствующие свойства будут храниться.

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