Коллекции, предметы, глаголы и дизайн интерфейса REST: что должны возвращать POST? - PullRequest
1 голос
/ 25 августа 2009

Я проектирую интерфейс REST, и я озадачен тем, что должен возвращать глагол insert / update / delete (как содержание ответа).Рассмотрим интерфейс для Invoice сущностей, доступный в api/invoices:

  • GET /api/invoices, возвращает список счетов
  • GET /api/invoices/123, возвращает счет с идентификатором 123
  • POST /api/invoices добавляет новый счет (идентификатор, созданный на сервере)
  • POST /api/invoices/123 обновляет счет с идентификатором 123
  • DELETE /api/invoices/123, удаляет счет с идентификатором 123

Совершенно очевидно, что должны возвращать первые два метода, но как насчет вставки / обновления / удаления?Очевидный ответ заключается в том, что add должен возвращать вновь созданный элемент (т. Е. Точно такой же ответ, как GET / api / invoices / id), update должен возвращать обновленный элемент (опять же, как GET) и delete, вероятно, ничего не должно возвращать (пустой контент).Все это имеет смысл и является целесообразным.

Но мои проблемы начинаются при рассмотрении предметов, которые не так просты, как сущность Invoice.Например, рассмотрим запрос add, который не только добавляет элемент, но и фактически должен вернуть некоторую дополнительную информацию об операции добавления: элемент был принят (успех), элемент является дубликатом (успех с информацией), элемент былигнорируется (успех с информацией, я не буду вдаваться в подробности, почему), элемент был отклонен (ошибка).Кроме того, в моем случае есть дополнительная информация, которую я хочу вернуть, например, информация об ответе, предварительно установленная для корзины в недавно добавленные элементы, падает.Я рассмотрел размещение всей дополнительной информации в заголовках http как своего рода внеполосную информацию (например, дополнительные коды состояния в диапазоне 200 и даже пользовательские заголовки), но это хак, и часть «ответа» может быть на самом деле больше, чемсам предмет.Итак, теперь я рассматриваю глагол add, чтобы вернуть совершенно новый тип, элемент, который содержит информацию о добавлении (статус, ответ, идентификатор нового элемента, perhpas весь новый элемент).Это, безусловно, выполняет свою работу, но я скучаю по хорошей симметрии, которая была у меня раньше.

Это было бы хорошей практикой (при добавлении элемента типа 'foo' возвращаемое значение имеет тип 'bar') иличто-нибудь, что я посмотрю через 6 месяцев и выдерну волосы, потому что я выпустил кошку из сумки?Если я придерживаюсь «любой доступ к foo возвращает foo, включая add», то после операции «add» клиенту придется сделать дополнительный вызов, чтобы получить информацию, которая ему действительно интересна (т. Е. «Response»).

Ответы [ 2 ]

1 голос
/ 25 августа 2009

Ваш ответ должен быть довольно сложным. Он не должен соответствовать входящему запросу. Мы используем JSON, и у нас есть некоторая дополнительная информация в дополнение к объекту.

Типичный ответ:

[{ "ID": the generated ID, "TYPE": the actual class name, "OBJECT": { the object } }]

POST должен вернуть объект, который был создан. Если у вас есть дополнительная информация (что не очень хорошая идея), вы можете указать это в ответном сообщении.

PUT должен вернуть результат обновления.

DELETE, как и GET, может просто возвращать статус.

Дополнительная информация в статусе не является взломом, поэтому коды статуса так открыты.

  • пункт был принят (успех) - статус 200 OK

  • элемент является дубликатом (успех с информацией) - я не уверен, какая возможная информация будет у вас сверх конечного созданного объекта, но это место для 20x - ОК с информацией ИНФО. 1020 *

  • пункт был проигнорирован (успех с информацией, я не буду вдаваться в подробности почему) - это неоднозначно. Я бы не назвал это успехом, я бы назвал это 40-кратным. Если вы не можете вдаваться в подробности, почему вы можете назвать это 20X - ИГНОРИРУЕМЫЙ

  • элемент был отклонен (ошибка). Это просто старое сообщение 40X ОТКАЗАНО.

0 голосов
/ 25 августа 2009

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

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