HTTP-СООБЩЕНИЕ с параметрами URL—запроса - хорошая идея или нет?[закрыто]

Question

Я разрабатываю API для перехода по протоколу HTTP, и мне интересно, является ли использование команды HTTP POST, но только с параметрами запроса URL и без тела запроса, хорошим способом.

Соображения:

• "Хороший веб-дизайн" требует, чтобы неидемпотентные действия отправлялись по ПОЧТЕ.Это неидемпотентное действие.
• Разрабатывать и отлаживать это приложение проще, когда параметры запроса присутствуют в URL-адресе.
• API не предназначен для широкого использования.
• Похоже, что выполнение запроса POST без тела потребует немного больше работы, напримерa Content-Length: 0 заголовок должен быть добавлен явно.
• Мне также кажется, что сообщение без тела немного противоречит ожиданиям большинства разработчиков и HTTP-фреймворков.

Есть ли еще какие-либо подводные камни или преимущества при отправке параметров в запросе POST через URL-запрос, а не в теле запроса?

Редактировать:Причина, по которой это рассматривается, заключается в том, что операции не являются идемпотентными и имеют побочные эффекты, отличные от извлечения.Видишь спецификация HTTP:

В частности, соглашение было установлено, что методы GET и HEAD НЕ ДОЛЖНЫ иметь значения для выполнения действия, отличного от извлечения.Эти методы следует считать "безопасными".Это позволяет пользовательским агентам представлять другие методы, такие как POST, ПОМЕСТИТЬ и УДАЛИТЬ, особым образом, чтобы пользователь был поставлен в известность о том, что запрашивается возможно небезопасное действие.

...

Методы также могут обладать свойством "идемпотентности" в том смысле, что (помимо проблем с ошибкой или истечением срока действия) побочные эффекты N > 0 идентичны запросы такие же, как и для одного запроса.Методы GET, HEAD, PUT и DELETE совместно используют это свойство.Кроме того, методы OPTIONS и TRACE ДОЛЖНЫ НЕ иметь побочных эффектов, и поэтому являются по своей сути идемпотентными.

Answer 1

Если ваше действие не является идемпотентным, то вы ДОЛЖЕН использование POST.Если вы этого не сделаете, вы просто напрашиваетесь на неприятности в дальнейшем. GET, PUT и DELETE методы являются требуемый быть идемпотентным.Представьте, что произошло бы в вашем приложении, если бы клиент предварительно извлекал все возможные GET запрос на вашу услугу - если это вызовет побочные эффекты, видимые клиенту, значит, что-то не так.

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

Думайте о части запроса URL-адреса как о команде ресурсу ограничить область текущего запроса.Обычно строки запроса используются для сортировки или фильтрации GET запрос (например ?page=1&sort=title) но я полагаю, что это имеет смысл на POST чтобы также ограничить область применения (возможно, как ?action=delete&id=5).

Answer 2

Все правы:придерживайтесь POST для неидемпотентных запросов.

Как насчет использования как строки запроса URI, так и содержимого запроса?Ну, это допустимый HTTP (см. примечание 1), так почему бы и нет!

Это также совершенно логично:URL-адреса, включая их строковую часть запроса, предназначены для определение местоположения Ресурсы.Принимая во внимание, что глаголы метода HTTP (POST - и его необязательное содержимое запроса) предназначены для указания действий, или что делать с Ресурсы.Это должны быть ортогональные проблемы.(Но они не являются красиво ортогональными для особого случая ContentType=application/x-www-form-urlencoded, см. Примечание 2 ниже.)

Примечание 1:Спецификация HTTP (1.1) не утверждает, что параметры запроса и содержимое являются взаимоисключающими для HTTP-сервера, который принимает запросы POST или PUT.Таким образом, любой сервер может свободно принимать и то, и другое.То есть.если вы пишете сервер, ничто не мешает вам принять оба варианта (за исключением, возможно, негибкой структуры).Как правило, сервер может интерпретировать строки запроса в соответствии с любыми правилами, которые он хочет.Он даже может интерпретировать их с помощью условной логики, которая ссылается и на другие заголовки, такие как Content-Type, что приводит к примечанию 2:

Примечание 2:если a веб- браузер это основной способ, которым люди получают доступ к вашему веб-приложению, и приложение/x-www-форма-urlencoded является типом контента, который они публикуют, тогда вы следует следуйте правилам для этого типа контента.И правила для application/x-www-form-urlencoded гораздо более конкретны (и, честно говоря, необычны):в этом случае вы должны интерпретировать URI как набор параметров, а не местоположение ресурса.[Это тот же самый вопрос полезности , который затронул Властелин;что может быть трудно использовать веб-формы для РАЗМЕЩЕНИЯ контента на вашем сервере.Просто объяснил немного по-другому.]

Примечание 3:для чего изначально предназначены строки запроса?RFC 3986 определяет строки HTTP-запроса как часть URI, которая работает как неиерархический способ определения местоположения ресурса.

На случай, если читатели, задающие этот вопрос, захотят спросить, что такое хорошая архитектура RESTful:шаблон архитектуры RESTful не требует, чтобы схемы URI работали определенным образом.Архитектура RESTful касается других свойств системы, таких как кэшируемость ресурсов, дизайн самих ресурсов (их поведение, возможности и представления) и то, удовлетворяется ли идемпотентность.Или, другими словами, достижение дизайна, который в высокой степени совместим с протоколом HTTP и его набором глаголов метода HTTP.:-) (Другими словами, архитектура RESTful не очень ориентирована на то, как ресурсы расположенный.)

Заключительная нота:иногда параметры запроса используются еще и для других целей, которые не являются ни поиском ресурсов, ни кодированием содержимого.Вы когда-нибудь видели параметр запроса типа 'PUT= true' или 'POST= true'?Это обходные пути для браузеров, которые не позволяют вам использовать методы PUT и POST.Хотя такие параметры рассматриваются как часть строки запроса URL (на проводе), я утверждаю, что они не являются частью запроса URL в духе.

Answer 3

Тебе нужны причины?Вот один из них:

Веб-форма не может быть использована для отправки запроса на страницу, использующую сочетание GET и POST.Если вы задаете методу формы значение GET, все параметры находятся в строке запроса.Если вы установите для метода формы значение POST, все параметры будут указаны в теле запроса.

Источник:Стандарт HTML 4.01, раздел 17.13 Подача формы

Answer 4

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

Преимущества / недостатки могут заключаться в том, как конкретные клиентские платформы работают с подпрограммами POST и GET в своем сетевом стеке, а также в том, как веб-сервер обрабатывает эти запросы.В зависимости от вашей реализации один подход может быть более эффективным, чем другой.Знание этого будет определять ваше решение здесь.

Тем не менее, с точки зрения программиста, я предпочитаю разрешать либо POST со всеми параметрами в теле, либо GET со всеми параметрами в URL и явно игнорировать параметры URL при любом запросе POST.Это позволяет избежать путаницы.

Answer 5

Я бы подумал, что все еще было бы достаточно RESTful иметь аргументы запроса, которые идентифицируют ресурс по URL, сохраняя при этом полезную нагрузку контента, ограниченную телом ПУБЛИКАЦИИ.Казалось бы, это отделяет соображения "Что я отправляю?" от "Кому я это отправляю?".

Answer 6

В ОТДЫХ у camp есть несколько руководящих принципов, которые мы можем использовать для стандартизации способа использования HTTP-глаголов.Это полезно при создании RESTful API, как это делаете вы.

В двух словах:GET должен быть доступен только для чтения, т. е.не влияет на состояние сервера.POST используется для создания ресурса на сервере.PUT используется для обновления или создания ресурса.УДАЛИТЬ используется для удаления ресурса.

Другими словами, если ваше действие API изменяет состояние сервера, REST рекомендует нам использовать POST / PUT /DELETE, но не GET.

Пользовательские агенты обычно понимают, что делать несколько сообщений плохо, и будут предупреждать об этом, потому что целью POST является изменение состояния сервера (например.оплачивайте товар на кассе), и вы, вероятно, не захотите делать это дважды!

Сравните с GET, который вы можете делать часто, как вам нравится (идемпотентный).

Answer 7

Я согласен - вероятно, безопаснее использовать GET-запрос, если вы просто передаете данные в URL, а не в теле.Видишь этот похожий вопрос для получения некоторых дополнительных просмотров всего ПОСТА + ПОЛУЧИТЕ концепцию.