Я проектирую интерфейс 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»).