Определение метода HTTP для передачи полезной нагрузки от клиента к серверу

Question

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

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

Я сомневаюсь, какой метод http подходит для этого?

GET: Если мы используем GET, мы можем отправить тело запроса, но рекомендуется, чтобы тело не имело семантики, связанной с запросом. Смотрите это: http-get-with-request-body

Так что я остался с POST или PUT, но это соответствует обновлению или созданию ресурса, и их использование может немного вводить в заблуждение.

Поэтому мой вопрос заключается в том, какой метод HTTP можно использовать в этом сценарии и который приемлем с точки зрения разработки RESTful.

Оцените ответ.

Я думаю использовать POST или PUT, так как нет ограничений по использованию тела запроса на стороне сервера.

EDIT:

Я думаю, что POST послужит моей цели. RFC HTTP RFC 7231 говорит, что POST может использоваться для: Предоставление блока данных, например полей, введенных в форму HTML, для процесса обработки данных

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

Answer 1

Имейте в виду, что GET должен использоваться только для извлечения данных , без побочных эффектов. То есть GET является одновременно безопасным и идемпотентом (подробнее см. здесь ).

---

Если операция предназначена для идемпотентности, перейдите к PUT:

4.3.4. PUT

Метод PUT запрашивает, чтобы состояние целевого ресурса было создано или заменено на состояние, определенное представлением, включенным в полезную нагрузку сообщения запроса. Успешное PUT данного представления предполагает, что последующее GET на том же целевом ресурсе приведет к отправке эквивалентного представления в ответе 200 (OK). [...]

В противном случае перейдите к POST, то есть поймать весь глагол :

4.3.3. POST

Метод POST запрашивает, чтобы целевой ресурс обработал представление, заключенное в запросе, в соответствии с собственной определенной семантикой ресурса. [...]

Answer 2

Так что мой вопрос в том, какой метод HTTP можно использовать в этом сценарии, который приемлем с точки зрения разработки RESTful.

Всемирная паутина примерно такая же RESTful ипример, как вы собираетесь найти, и HTML-формы поддерживают только GET (у которого не должно быть тела запроса ) и POST.Так что POST должно быть в порядке (и это так).

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

Я не могу понять, почемуПолезная нагрузка HTTP GET запрещена

Полезная нагрузка HTTP GET запрещена, поскольку стандарт гласит «не делай этого».

Я полагаю, что написано так, чтобы упроститьправила кеширования ответа.Как написано, реализации кеша должны беспокоиться только о данных заголовка (включая информацию о начале строки).

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

Answer 3

Существует PATCH метод post, который предназначен для изменения вещей, может быть, это то, что вы ищете

Answer 4

Я бы выбрал POST, потому что в REST PUT используется для создания нового ресурса, такого как пользователь.