Определение метода HTTP для передачи полезной нагрузки от клиента к серверу
У меня есть вариант использования, когда некоторый контекст необходимо передать из пользовательского интерфейса в серверную часть, а серверная часть должна принять решение и отправить ответ на основе этого контекста.
Это может быть достигнуто путем отправки контекста через тело запроса, а на стороне сервера путем анализа тела запроса представление может быть отправлено в теле ответа.
Я сомневаюсь, какой метод http подходит для этого?
GET: если мы используем GET, мы можем отправить тело запроса, но рекомендуется, чтобы тело не имело никакой семантики, связанной с запросом. Смотрите это: http-получить с телом запроса
Итак, у меня остались POST или PUT, но они соответствуют обновлению или созданию ресурса, и их использование может немного вводить в заблуждение.
Итак, мой вопрос заключается в том, что является подходящим методом HTTP, который можно использовать в этом сценарии, приемлемом с точки зрения дизайна RESTful.
Оцените ответ.
Я думаю использовать POST или PUT, так как нет ограничений на использование тела запроса на стороне сервера.
Обновлено:
Я думаю, что POST послужит моей цели. В rfc HTTP RFC 7231 сказано, что POST можно использовать для: Предоставление блока данных, таких как поля, введенные в HTML-форму, в процесс обработки данных.
Таким образом, процесс обработки данных для меня — это внутренний сервер, а HTML-форма эквивалентна любому элементу пользовательского интерфейса. Таким образом, я могу использовать метод POST для отправки данных в серверную часть и отправки существующего представления ресурсов в качестве тела ответа с кодом http-статуса 200.
Эй, Рамакришна! Вы недавно задали этот вопрос, и я потратил время и усилия, чтобы ответить на него. Так что я очень ценю любой Обратная связь в моем отвечать.
Привет, Кассиомолин. Извините, что долго добавлял комментарий. Я очень ценю ваш ответ. Мне очень помогло. Спасибо
Ответы 4
Я бы выбрал POST, потому что в REST PUT используется для создания нового ресурса, такого как пользователь.
На самом деле операция PUT является идемпотентной. PUT используется для создания, если ресурс отсутствует, иначе для обновления ресурса. Но в любом случае, спасибо за участие
Существует метод публикации PATCH, который предназначен для изменения вещей, возможно, это то, что вы ищете.
На самом деле я не собираюсь менять какой-либо ресурс, а скорее хочу решить, какое представление ресурса необходимо отправить со стороны сервера на основе тела запроса. Ресурс уже существует на стороне сервера
CONNECT используется для проксирования по запросу, и, поскольку вы отправляете данные в зависимости от входящего запроса, заголовок CONNECT может быть полезным.
Пожалуйста, имейте в виду, что GET должен использоваться для только получение данных без побочных эффектов. То есть GET является одновременно безопасно и идемпотент (см. подробнее здесь).
Если операция должна быть идемпотентной, используйте PUT:
The
PUTmethod requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload. A successfulPUTof a given representation would suggest that a subsequentGETon that same target resource will result in an equivalent representation being sent in a200(OK) response. [...]
В противном случае выберите POST, который является поймать все глагол:
The
POSTmethod requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics. [...]
Я думаю, что POST послужит моей цели. В rfc связь сказано, что POST можно использовать для Предоставление блока данных, таких как поля, введенные в HTML-форму, в процесс обработки данных..
@RamakrishnaShastri Действительно. Кажется, это самый подходящий метод для вашей ситуации.
So my question is what is the appropriate HTTP method that could be used in this scenario which is acceptable in the RESTful design standpoint.
Всемирная паутина является примерно таким же RESTful примером, какой вы собираетесь найти, а HTML-формы поддерживают только GET (который не должно иметь тело запроса) и POST. Так что POST должно быть хорошо (и это так).
В более общем смысле POST можно использовать для чего угодно; другие методы следует использовать, когда они лучше подходят семантически. Например, вы могу используете POST, чтобы сделать ресурс недоступным, но DELETE является более явным, и общие компоненты могут делать разумные вещи, потому что они распознают семантику. PUT — лучший выбор, чем POST, когда вы намереваетесь предоставить серверу новое представление ресурса и так далее.
I am not able to understand why the payload of the HTTP GET is forbidden
Полезная нагрузка HTTP GET запрещена, потому что стандарт говорит «не делайте этого».
По-моему, так написано для упрощения правил кеширования ответа. Как написано, реализации кэша должны заботиться только о данных заголовка (включая информацию о стартовой строке).
Но это может быть так же просто, как тот факт, что более старые версии стандарта не требовали, чтобы универсальные компоненты делали что-то конкретное с телом сообщения GET-запроса, и поэтому современные спецификации говорят «не делайте этого», чтобы для поддержания обратной совместимости. (Одним из важных ограничений при проектировании долгоживущих систем является то, что вы не ломаете старые реализации.)
Спасибо за ответ. Но я не могу понять, почему полезной нагрузке HTTP GET запрещено иметь семантику запроса, и даже если она имеет, запрещено отправлять представление со стороны сервера на основе этой семантики. Если бы вы могли пролить свет на это, было бы здорово
Используйте метод Post для того же.