Различают Сохранить и Отправить в Rest API

Question

Вопрос о сохранении данных формы в MongoDB с использованием Rest API.У меня есть три различных сценария.

1. Сохранение и возврат (Первое сохранение данных частично и возврат идентификатора для будущего возврата).
2. Отправка уже сохраненных данных (Второй раз, заполнение формыи сделайте окончательную отправку, чтобы я мог запустить другой рабочий процесс.)
3. Отправить напрямую (отправьте полную форму в первый раз, верните идентификатор и запустите рабочий поток)

ДляВ приведенном выше сценарии я описал ресурс API ниже

POST --> v1/applications   (This will save data and return id)
PUT --> v1/applications/{id} (This will retrieve data using id parameter and update that data)

Моя путаница заключается в том, как дифференцировать оба API, будь то только сохранение или окончательный вызов отправки, потому что я должен начать рабочий процесс после окончательной отправки.Могу ли я использовать какой-либо параметр запроса, как показано ниже, чтобы указать, отправлять или сохранять?

POST --> v1/applications?submit=true or false   (This will save data and return id)
PUT --> v1/applications/{id}?submit=true or false (This will retrieve data using id parameter and update that data)

Или у нас есть какой-то лучший подход для разграничения сохранения и отправки в этом API?

Answer 1

Моя путаница заключается в том, как дифференцировать оба API, будь то только сохранение или окончательный вызов отправки, потому что я должен начать рабочий процесс после окончательной отправки.Могу ли я использовать какой-либо параметр запроса, как показано ниже, для указания отправки или сохранения?

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

PUT /applications/12345

Version: 1
Status:  Draft

PUT /applications/12345

Version: 2
Status:  Final

Имейте в виду, что URI является идентификатором для ресурса (он же документ).Выполнение интересной работы является побочным эффектом передачи документов.См. Джим Уэббер .

Если бы вы делали все в HTML, который изначально не поддерживает PUT, вы, вероятно, использовали бы POST, с одной формой для редактирования и другой для завершения,или, может быть, одна форма, предназначенная для обработки обоих вариантов использования.

Один вопрос, поэтому при первом сохранении или прямой отправке следует использовать POST / приложения.Я прав?

Это общий выбор, но не обязательный.Реальное различие заключается в следующем: создаем ли мы новый ресурс по целевому URL ?

Если да, то PUT, POST, PATCH - все возможности.

Если нет - если мы отправляем запрос на один ресурс сервера, ожидая, что созданный ресурс будет где-то еще, тогда POST является подходящим выбором.

Answer 2

В стиле RESTFul параметр запроса означает, что есть что-то, отличное от сценариев, что означает, что вы не можете определить правило для использования действия.Лучше документировать эту функцию в URL, чем в реальном документе (никто не будет внимательно его читать). Я думаю, в вашем сценарии это может быть лучше, как:

POST v1/applications/add/
PUT  v1/applications/{id}

Кстати, попробуйте не делать этогоидеально подходит один раз, хороший сервис нуждается в проверке и обслуживании.