"Лучшая" практика для спокойного ответа POST

Так что здесь ничего нового. Я просто пытаюсь получить разъяснения и не могу найти их в других сообщениях.

Я восстанавливаю новый ресурс, скажем:

/books (POST)

с телом:

{
  title: 'The Lion, the Witch and the Wardrobe',
  author: 'C. S. Lewis'
}

Я знаю, что должен вернуть 201 (Created) с заголовком Location нового ресурса:

Location: /books/12345

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

Я часто отвечал так:

{
  id: 12345,
  title: 'The Lion, the Witch and the Wardrobe',
  author: 'C. S. Lewis'
}

Я сделал это по нескольким причинам:

  1. Я написал api для интерфейсных фреймворков, таких как angularjs. В моем конкретном случае я использую ресурсы angular, и мне часто нужен только идентификатор ресурса, чтобы найти его. Если бы я не вернул идентификатор в теле ответа, мне нужно было бы извлечь его из заголовка Location.
  2. В GET всех книг я обычно возвращаю весь объект, а не только идентификатор. В этом смысле мой клиентский код не должен различать, откуда брать идентификатор (заголовок или тело местоположения).

Теперь я знаю, что я действительно нахожусь здесь в серой зоне, но большинство людей говорят, что возвращение всего ресурса - это «плохая» практика. Но что делать, если сервер изменяет / добавляет информацию к ресурсу. Он определенно добавляет идентификатор, но может также добавлять другие вещи, такие как временная метка. В случае, если я не возвращаю весь ресурс, действительно ли лучше выполнить POST, вернуть идентификатор, а затем попросить клиента выполнить GET для получения нового ресурса.


person lostintranslation    schedule 05.10.2013    source источник
comment
Я лично предпочитаю пустое тело для ответов POST. Разве значение заголовка RESTful Location не должно быть URI (уникальным идентификатором ресурса)? Так что, возможно, вам стоит использовать его как идентификатор, а не анализировать его, чтобы определить внутренний идентификатор сервера. ИМО, потребители RESTful API должны перемещаться, используя предоставленные гиперссылки, а не путь сборки, угадывая, где конкретный сервер находит ресурсы ... И в конце концов, разве клиент уже не знает состояние только что созданного ресурса? его повторение означает бесполезную трату сетевых ресурсов.   -  person ch4mp    schedule 22.02.2019
comment
Для Create / Insert, Status 201 - CREATED, расположение заголовка → localhost: 8080 / employee / 1 (см. : здесь)   -  person Hassan Tareq    schedule 23.08.2019


Ответы (2)


Возврат всего объекта при обновлении может показаться не очень актуальным, но я с трудом понимаю, почему возвращение всего объекта при его создании было бы плохой практикой в ​​нормальном случае использования. Это было бы полезно, по крайней мере, для того, чтобы легко получить идентификатор и, при необходимости, временные метки. На самом деле это поведение по умолчанию, полученное при построении лесов с помощью Rails.

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

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

person Daniel Perez    schedule 05.10.2013
comment
Я знаю, что это устарело, но я могу привести убедительный аргумент в пользу использования GET после вашего POST. В спецификации http / 1.1 любой исторический инструмент может игнорировать настройки кеша, переданные из вашего ответа GET ... поэтому, если ваш пользователь использует кнопку возврата в браузере, чтобы вернуться на эту страницу после того, как вы обновили ее с помощью POST, он может использовать устаревшие кэшированные данные из исходного GET. Поэтому, если вы повторно используете GET, вы можете обновить кеш и получить лучший снимок того, как страница выглядела, когда они ушли ... - person Shaded; 10.11.2015
comment
@Shaded Если API предназначен для использования и приложениями, то ваш аргумент в пользу создания двух запросов не работает. Там вы обычно кэшируете данные, сохраняя объекты типа модели в памяти, что обычно делается с ответом на запросы POST. Что касается браузеров, ответ на запрос POST на самом деле не повредит, пока существует конечная точка GET api. - person Jeehut; 16.03.2017
comment
Я подписываюсь на то, что здесь говорит Даниэль. Даже если вы проверите зрелые фреймворки, такие как Spring Data, они всегда возвращают весь объект после его сохранения. Я думаю, что это хорошая практика, поскольку в вашем клиенте вы сохраните обратный путь к серверу, чтобы получить ту же информацию. - person frandevel; 09.12.2019

Возврат нового объекта соответствует принципу REST «Единый интерфейс - манипулирование ресурсами через представления». Полный объект - это представление нового состояния созданного объекта.

Вот действительно отличный справочник по разработке API: Лучшие практики для Разработка прагматичного RESTful API

Здесь вы найдете ответ на ваш вопрос: Обновления и создание должны возвращать представление ресурса

Он говорит:

Чтобы потребителю API не приходилось снова обращаться к API для обновленного представления, пусть API возвращает обновленное (или созданное) представление как часть ответа.

Мне это кажется приятным прагматичным, и это согласуется с принципом REST, о котором я упоминал выше.

person grahamesd    schedule 09.03.2015
comment
как насчет возврата всего набора соответствующих объектов? Таким образом, возможная сортировка может выполняться на стороне сервера, что упрощает интерфейсную реализацию. - person phil294; 05.01.2017
comment
Но эти лучшие практики не самые лучшие. Автор заявляет, что HATEOAS, который важен так же, как и другие принципы, не должен использоваться, потому что он не готов. HATEOAS никогда не будет готов, потому что все принципы RESTful - это просто принципы архитектурного проектирования, а не конкретная реализация. Цитируемая ссылка касается видения автора RESTful API, который вообще не является RESTful из-за отказа от HATEOAS. Поэтому это не лучшая ссылка :) - person marcinn; 24.07.2019
comment
@marcinn - вы заметите, что в исходном вопросе были кавычки вокруг «Лучшего», я думаю, потому что в этой области существует много мнений. Ссылка, на которую я указал, кажется мне практичной. Если у вас есть лучшая ссылка, поделитесь ею. Я всегда готов узнать больше. - person grahamesd; 13.09.2019
comment
@grahamesd Реализация - это другое дело, чем принцип / шаблон архитектурного проектирования. Никто не может ожидать, что HATEOAS когда-нибудь будет готов, но есть шанс, что кто-то создаст реализацию, приемлемую для многих. Винай также писал о сопоставлении http-методов с URL-адресами и конкретными операциями (CRUD), заявил, что управление версиями с помощью префиксов URL-адресов более прагматично, написал, что фильтрация по параметрам запроса - это способ пойти ... это нормально, но все это мало делать с RESTful архитектурой. Он писал о каком-то контракте. Это нормально для HTTP API, но не называйте это RESTful. - person marcinn; 13.09.2019
comment
@grahamesd Вот несколько сообщений, объясняющих это: - medium.com /@andrea.chiarelli/ - restfulapi.net - person marcinn; 13.09.2019
comment
@grahamesd Хорошее объяснение. Но при неудачной попытке patch или post также должно возвращаться сообщение об ошибке в расходном формате. Может, это нужно добавить к вашему ответу ...? Подробнее на vinaysahni.com/ - person Dinko Pehar; 24.09.2019