Зачем нам нужно что-то большее, чем HTTP GET, PUT, POST?
https://stackoverflow.com/questions/147187
-
02-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Какова практическая польза от использования HTTP GET, PUT, DELETE, POST, HEAD?Почему бы не сосредоточиться на их поведенческих преимуществах (безопасность и идемпотентность), забыв об их именах, и не использовать GET, PUT или POST в зависимости от того, какое поведение нам нужно?
Почему бы нам не использовать только GET, PUT и POST (и отбросить HEAD, DELETE)?
Решение
Подход [REST][1] использует POST, GET, PUT и DELETE для реализации правил CRUD для веб-ресурса.Это простой и удобный способ предоставления объектов запросам в Интернете.Это веб-сервисы без накладных расходов.
Просто чтобы прояснить смысловые различия.Каждая операция довольно индивидуальна.Дело в том, чтобы иметь хорошие HTTP-методы, которые имеют четкое и четкое значение.
POST создает новые объекты.У URI нет ключа;он принимает тело сообщения, определяющее объект.SQL-вставка.[Редактировать Хотя нет технической причины, по которой у POST нет ключа, ребята из REST настоятельно рекомендуют, чтобы POST имел особое значение как CREATE, у него не должно быть ключа.]
GET извлекает существующие объекты.URI может есть ключ, зависит от того, выполняете ли вы одноэлементный GET или GET списка.SQL выбор
PUT обновляет существующий объект.У URI есть ключ;Он принимает тело сообщения, которое обновляет объект.Обновление SQL.
DELETE удаляет существующий объект.У URI есть ключ.SQL-удаление.
Можете ли вы обновить запись с помощью POST вместо PUT?Не без внесения некоторой двусмысленности.Глаголы должны иметь однозначное воздействие.Кроме того, у POST URI нет ключа, тогда как у PUT должен быть ключ.
Когда я публикую сообщение, я ожидаю 201 CREATED.Если я этого не понимаю, значит, что-то не так.Точно так же, когда я СТАВЛЮ, я ожидаю 200 ОК.Если я этого не понимаю, значит, что-то не так.
Полагаю, вы могли бы настаивать на некоторой двусмысленности, когда POST выполняет либо POST, либо PUT.URI должен быть другим;также связанное сообщение может быть другим.Обычно люди, использующие REST, берут пример с SQL, где INSERT и UPDATE — это разные глаголы.
Вы можете сделать так, чтобы UPDATE вставлялся, если запись не существует, или обновлялся, если запись существует.Однако проще, если UPDATE означает UPDATE, а отсутствие обновления означает, что что-то не так.Секретный возврат к INSERT делает операцию неоднозначной.
Если вы не создаете интерфейс RESTful, то для получения, создания/обновления обычно используются только GET и POST.Обычно существуют различия в URI или в содержании сообщений, чтобы различать POST и PUT, когда человек нажимает кнопку «Отправить» в форме.Однако это не очень чисто, поскольку ваш код должен определить, находитесь ли вы в случае POST=create или POST=update.
Другие советы
ПОЧТА не имеет никаких гарантий безопасность или идемпотентность.Это одна из причин ПОМЕЩАТЬ и УДАЛИТЬ— и PUT, и DELETE идемпотентны (т. е. 1+N идентичных запросов имеют тот же конечный результат, что и всего лишь 1 запрос).
ПОМЕЩАТЬ используется для параметр состояние ресурса по данному URI.Когда вы отправляете ПОЧТА запрос к ресурсу по определенному URI, этот ресурс не должна быть заменены по содержанию.В лучшем случае это должно быть добавлено к.Вот почему POST не является идемпотентным — в случае добавления POSTS каждый запрос будет добавлять к ресурсу (например, публиковать новый сообщение на дискуссионный форум каждый раз).
УДАЛИТЬ используется для обеспечения того, чтобы ресурс по заданному URI был удален с сервера. ПОЧТА обычно не следует использовать для удаления, за исключением случая представление просьба удалить.Опять же, URI ресурса, к которому вы отправляете POST, в этом случае не должен быть URI ресурса, который вы хотите удалить.Любой ресурс, к которому выполняется POST, — это ресурс, который принимает данные POST для добавления к себе, добавления в коллекцию или для обработки каким-либо другим способом.
ГОЛОВА используется, если вас интересуют только заголовки запроса GET, и вы не хотите тратить пропускную способность на реальный контент.Это приятно иметь.
Зачем нам нужно больше, чем POST?Он позволяет данным передаваться в обоих направлениях, так зачем же нужен GET?Ответ в принципе такой же, как и на ваш вопрос.Стандартизируя основные ожидания от различных методов, другие процессы смогут лучше знать, что делать.
Например, промежуточные прокси-серверы кэширования могут иметь больше шансов сделать правильные действия.
Подумайте, например, о HEAD.Если прокси-сервер знает, что означает HEAD, он может обработать результат предыдущего запроса GET, чтобы предоставить правильный ответ на запрос HEAD.И он может знать, что POST, PUT и DELETE не должны кэшироваться.
Никто не опубликовал тот ответ, который я искал, поэтому я попытаюсь сам суммировать все моменты.
Глава 8 раздела «Веб-службы RESTful» «Перегрузка POST» гласит:«Если вы хотите вообще обойтись без PUT и DELETE, полностью RESTful предоставляет безопасные операции с ресурсами через GET, а все остальные операции — через перегруженный POST.Это нарушает мою ресурсно-ориентированную архитектуру, но соответствует менее строгим правилам REST».
Суммируя, замена PUT/DELETE на POST усложняет чтение API, а вызовы PUT/DELETE больше не являются идемпотентными..
В мире:
идемпотентность
Еще несколько слов:
GET = безопасный + идемпотентный
PUT = идемпотент
УДАЛИТЬ = идемпотент
POST = ни безопасный, ни идемпотентный
«Идемпотентность» просто означает, что вы можете делать это снова и снова, и он всегда будет делать одно и то же.
Вы можете повторно отправить запрос PUT (обновление) или DELETE столько раз, сколько захотите, и каждый раз он будет иметь один и тот же эффект, однако желаемый эффект изменит ресурс, поэтому он не будет считаться «безопасным».
Запрос POST должен создавать новый ресурс при каждом запросе, а это означает, что эффект каждый раз будет разным.Поэтому POST не считается безопасным или идемпотентным.
Такие методы, как GET и HEAD, представляют собой просто операции чтения и поэтому считаются «безопасными», а также идемпотентными.
На самом деле это очень важная концепция, поскольку она обеспечивает стандартный/согласованный способ интерпретации HTTP-транзакций;это особенно полезно в контексте безопасности.
Не все хостеры не поддерживают PUT, DELETE.
Я задал этот вопрос, в идеальном мире у нас были бы все глаголы, но....:
HEAD действительно полезен для определения настроек часов данного сервера (с точностью до 1 секунды или времени прохождения сигнала по сети, в зависимости от того, что больше).Это также отлично подходит для получения цитат из Футурамы со Slashdot:
~$ curl -I slashdot.org HTTP/1.1 200 OK Date: Wed, 29 Oct 2008 05:35:13 GMT Server: Apache/1.3.41 (Unix) mod_perl/1.31-rc4 SLASH_LOG_DATA: shtml X-Powered-By: Slash 2.005001227 Икс-Фрай:Это шоу цыпочек.Я предпочитаю программы жанра:Самый пустой бланк в мире. Cache-Control: private Pragma: private Connection: close Content-Type: text/html; charset=iso-8859-1
Для КУЛЬ, -I — это вариант выполнения запроса HEAD.Чтобы получить текущую дату и время данного сервера, просто выполните
curl -I $server | grep ^Date
Чтобы ограничить двусмысленность, которая позволит лучше/упрощать повторное использование наших простых API REST.
Вы можете использовать только GET и POST, но тогда вы потеряете некоторую точность и ясность, которые приносят PUT и DELETE.POST — это операция с подстановочными знаками, которая может означать что угодно.Поведение PUT и DELETE очень четко определено.Если вы думаете об API управления ресурсами, то GET, PUT и DELETE, вероятно, охватывают 80–90% необходимой функциональности.Если вы ограничитесь GET и POST, то доступ к 40–60% вашего API будет осуществляться с использованием плохо определенного POST.
Веб-приложения, использующие GET и POST, позволяют пользователям создавать, просматривать, изменять и удалять свои данные, но делают это на уровне выше команд HTTP, изначально созданных для этих целей.Одна из идей, лежащих в основе REST, — это возврат к первоначальному замыслу дизайна Интернета, при котором для каждой команды CRUD существуют определенные операции HTTP.
Кроме того, команду HEAD можно использовать для улучшения взаимодействия с пользователем при загрузке (потенциально больших) файлов.Вы вызываете HEAD, чтобы узнать, насколько большим будет ответ, а затем вызываете GET, чтобы фактически получить содержимое.
См. следующее связь для наглядного примера.Он также предлагает один из способов использования http-метода OPTIONS, который здесь еще не обсуждался.
Существуют http-расширения, такие как WebDAV, которые требуют дополнительных функций.
Вероятно, причиной этого стала война веб-серверов, имевшая место в прежние времена.
В HTTP 1.0 был написан в 1996 году, там были только GET, HEAD и POST..Но как вы можете видеть в Приложение Д, продавцы начали добавлять свои вещи.Поэтому, чтобы сохранить HTTP-совместимость, они были вынуждены сделать HTTP 1.1 в 1999 г..
Тем не менее, HTTP/1.0 недостаточно учитывает влияние иерархических прокси, кэширования, необходимости постоянных связей или виртуальных хостов.Кроме того, распространение не полностью внедренных приложений, называющих себя «http/1.0», потребовало изменение версии протокола, чтобы два сообщения сообщались, чтобы определить истинные возможности друг друга.
Эта спецификация определяет протокол, называемый «HTTP/1.1».Этот протокол включает в себя более строгие требования, чем HTTP/1.0, чтобы обеспечить надежную реализацию своих функций.
GET, PUT, DELETE и POST — это пережитки той эпохи, когда второкурсники думали, что веб-страницу можно свести к нескольким высокопарным принципам.
В настоящее время большинство веб-страниц представляют собой составные объекты, которые содержат некоторые или все эти примитивные операции.Например, на странице могут быть формы для просмотра или обновления информации о клиентах, которые, возможно, охватывают несколько таблиц.
Обычно я использую $_REQUEST[] в php, не особо заботясь о том, как поступила информация.Я бы предпочел использовать методы GET или PUT, основываясь на эффективности, а не на базовых (множественных) парадигмах.
