Правильный (RESTful) HTTP-метод для обработки смешанных / пакетных запросов

Question

У меня есть приложение, которое должно отправлять несколько (изменения) запросов на сервер одновременно. Эти запросы отправляются в пакете, представленном объектом JSON. Запросы могут быть любого (изменения) типа (например, создания, обновления, удаления).

JSON выглядит примерно так:

[
  { "delete": { "id": "to delete" } },
  { "update": { "id": "to update", "data": {} } },
  { "create": { "data": {} } },
  ...
]

Мой вопрос прост:

Если бы я отправлял их на сервер по одному, я бы использовал DELETE, PUT или POST, в зависимости от характера операции, но, поскольку я потенциально отправляю пакет содержащий все три типа запросов, я не уверен, какой метод является наиболее подходящим (кроме DELETE).

Какой правильный метод HTTP использовать в этом случае?

Спасибо.

Answer 1

Правильный метод для использования - это метод POST, так как вы создаете ресурс пакетного процесса. Кроме того, вы должны ответить кодом статуса 202 Accepted, в котором указано «Запрос принят к обработке, но обработка не завершена». (RFC 2616)

Надеюсь, это поможет!

UPDATE:

Это должно определенно быть методом POST, потому что этот запрос НЕ идемпотентен. Прежде чем продолжить, пожалуйста, посмотрите Что такое идемпотентность в методах HTTP? и Действительно ли REST DELETE идемпотентны? .

Если этот запрос делается несколько раз, он может иметь n побочных эффектов (поскольку он создает ресурсы)!

Я отозвал свой комментарий к рекомендации PUT, потому что я неправильно указал - PUT должен быть идемпотентом.

Answer 2

Если бы я отправлял их на сервер по одному, я бы использовал DELETE, PUT или POST в зависимости от характера операции, но так как я отправляю пакет, потенциально содержащий все три типа запросов Я не уверен, какой метод является наиболее подходящим (кроме DELETE).

Какой правильный метод HTTP использовать в этом случае?

«Это зависит».

Ключевой момент заключается в следующем: семантика http применяется к ресурсам, которые находятся в домене интеграции. Тот факт, что отправляемые вами представления интересным образом влияют на модель предметной области, не имеет значения.

Выбранный вами метод должен иметь небезопасную семантику, поскольку вы поощряете изменение исходного сервера. Вам также нужен метод, в котором тело сообщения имеет смысл. Из методов, определенных в спецификации HTTP, у вас есть PUT и POST - любой из них - fine . PATCH также может быть подходящим, в зависимости от того, можете ли вы сделать эту коллекцию изменений атомарно.

Пример: предположим, что мы на самом деле делаем тело сообщения и помещаем его в очередь для обработки «позже». Часть REST берет эту реализацию и одевает ее в маскировку HTTP.

Либо PUT, либо POST идеально подходят для этого. Использование POST для добавления чего-либо в очередь не должно быть большим сюрпризом. PUT аналогичен вставке сообщения в хранилище значений ключей.

HTTP - это протокол приложения, доменом приложения которого является «передача документов по сети». - Джим Уэббер

На вашем клиенте есть документ , в котором описываются изменения, которые вы хотите внести в модель вашего домена. Вы используете HTTP для передачи копии этого документа на сервер. POST работает для этого? Да. PUT работает для этого? тоже да.

Рассмотрим этот ресурс, что означает именно то, что написано на банке

/newest-message-in-queue

Можете ли вы обновить этот ресурс, отправив новое представление через POST? Конечно. Можете ли вы обновить этот ресурс, отправив PUT? Конечно. Будут ли побочные эффекты на объектах домена работать в любом случае? Да.

Может ли клиент определить разницу между этим и изменением значения в хранилище значений ключей? Нет <- и в этом все дело; мы замаскируем нашу реализацию за общей семантикой хранилища документов, чтобы мы могли воспользоваться имеющимися в наличии продуктами. </p>

Answer 3

Ну, AFAIK, такого способа не существует. Вы можете использовать только json, как в вашем посте, с новым POST запросом.

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