Какова практическая польза от использования 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 Select
PUT обновляет существующий объект. URI имеет ключ; Он принимает тело сообщения, которое обновляет объект. Обновление SQL.
DELETE удаляет существующий объект. URI имеет ключ. SQL Delete.
Можете ли вы обновить запись с помощью POST вместо PUT? Не без некоторой двусмысленности. Глаголы должны иметь однозначные последствия. Кроме того, POST URI не имеет ключа, где PUT должен иметь ключ.
Когда я отправляю POST, я ожидаю, что 201 СОЗДАН. Если я этого не сделаю, что-то не так. Точно так же, когда я PUT, я ожидаю 200 OK. Если я не получу этого, что-то не так.
Я полагаю, вы могли бы настаивать на некоторой двусмысленности, когда POST делает POST или PUT. URI должен быть другим; также связанное сообщение может быть другим. Как правило, люди REST берут свое решение от SQL, где INSERT и UPDATE - разные глаголы.
Вы можете указать, что UPDATE должен вставить, если запись не существует или не обновляется, если запись существует. Тем не менее, это проще, если UPDATE означает UPDATE и отказ в обновлении означает что-то неправильно. Секретный откат к INSERT делает операцию неоднозначной.
Если вы не создаете интерфейс RESTful, тогда типично использовать GET и POST для извлечения и создания/обновления. Как правило, различия в URI или различия в содержании сообщений различаются между POST и PUT, когда человек нажимает кнопку submit на форме. Это, однако, не очень чистое, потому что ваш код должен определить, находитесь ли вы в случае POST = create или POST = update.
POST не имеет гарантий безопасность или idempotency. Эта одна причина для PUT и DELETE -both PUT и DELETE являются идемпотентными (то есть 1 + N одинаковых запросов имеют тот же конечный результат, что и один запрос).
PUT используется для установки состояния ресурса при заданном URI. Когда вы отправляете запрос POST к ресурсу в определенном URI, этот ресурс не должен быть заменен содержимым. В лучшем случае его следует добавить. Вот почему POST не является идемпотентным - в случае добавления POSTS каждый запрос добавляется к ресурсу (например, каждый раз публикует новое сообщение в дискуссионный форум).
DELETE используется для обеспечения того, чтобы ресурс с заданным URI удалялся с сервера. POST обычно не используется для удаления, за исключением случая отправки запроса на удаление. Опять же, URI ресурса, который вы должны были бы POST, в этом случае не должен быть URI для ресурса, который вы хотите удалить. Любой ресурс, для которого вы используете POST, является ресурсом, который принимает POSTED-данные для добавления к себе, добавления в коллекцию или для обработки другим способом.
HEAD используется, если все, о чем вы заботитесь, это заголовки запроса GET, и вы не хотите чтобы тратить полосу пропускания на фактический контент. Это приятно иметь.
Почему нам нужно больше, чем POST? Он позволяет передавать данные в обоих направлениях, поэтому зачем нужно GET? Ответ в основном такой же, как и для вашего вопроса. Стандартизируя основные ожидания различных методов, другие процессы могут лучше знать, что делать.
Например, промежуточные кэширующие прокси могут иметь больше шансов сделать правильную вещь.
Подумайте о главе, например. Если прокси-сервер знает, что означает HEAD, он может обработать результат из предыдущего запроса GET, чтобы предоставить правильный ответ на запрос HEAD. И он может знать, что POST, PUT и DELETE не должны кэшироваться.
Никто не отправил ответ, который я искал, поэтому я попытаюсь кратко изложить свои замечания.
"Раздел RESTful Web Services" в разделе 8 "Перегрузка POST" гласит: "Если вы хотите обойтись без PUT и DELETE вообще, его полностью RESTful предоставляет безопасные операции над ресурсами через GET и все другие операции через перегруженный POST. это нарушает мою ресурсо-ориентированную архитектуру, но она соответствует менее строгим правилам REST".
Короче говоря, замена PUT/DELETE в пользу POST делает API более трудным для чтения, а вызовы PUT/DELETE больше не являются идемпотентными.
Одним словом:
идемпотентность
Еще несколько слов:
GET = безопасный + idempotent
PUT = idempotent
DELETE = idempotent
POST = ни безопасный, ни идемпотентный
"Идемпотент" означает, что вы можете делать это снова и снова, и он всегда будет делать то же самое.
Вы можете повторно выполнить запрос PUT (update) или 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 X-Fry: That a chick show. I prefer programs of the genre: World Blankiest Blank. Cache-Control: private Pragma: private Connection: close Content-Type: text/html; charset=iso-8859-1
Для cURL, -I - это опция для выполнения запроса HEAD. Чтобы получить текущую дату и время для данного сервера, просто сделайте
curl -I $server | grep ^Date
Чтобы ограничить двусмысленность, что позволит лучше/проще повторно использовать наш простой REST apis.
Вы можете использовать только GET и POST, но затем вы теряете определенную точность и ясность, которые PUT и DELETE приносят. POST - это подстановочная операция, которая может означать что угодно. Поведение PUT и DELETE очень хорошо определено. Если вы думаете о API управления ресурсами, то GET, PUT и DELETE, вероятно, покрывают 80% -90% требуемой функциональности. Если вы ограничиваете себя GET и POST, то 40% -60% вашего api получают с помощью плохо указанного POST.
Веб-приложения, использующие GET и POST, позволяют пользователям создавать, просматривать, изменять и удалять свои данные, но делать это на уровне выше HTTP-команд, первоначально созданных для этих целей. Одна из идей, лежащих в основе REST, - это возврат к первоначальному намерению дизайна Web, при котором существуют определенные HTTP-операции для каждого CRUD-глагола.
Кроме того, команда HEAD может использоваться для улучшения пользовательского интерфейса для (потенциально больших) загрузок файлов. Вы вызываете HEAD, чтобы узнать, насколько велика будет реакция, а затем вызовите GET для фактического извлечения содержимого.
См. следующий ссылка для иллюстративного примера. Он также предлагает один из способов использования метода OPTIONS http, который еще не обсуждался здесь.
Существуют HTTP-расширения, такие как WebDAV, которые требуют дополнительного функционального использования.
Война в веб-сервере с ранних дней, вероятно, вызвала ее.
В HTTP 1.0, написанном в 1996 году, были только GET, HEAD и POST. Но, как вы можете видеть в Приложение D, поставщики начали добавлять свои собственные вещи. Таким образом, чтобы поддерживать совместимость с 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, основанные на эффективности, а не лежащие в основе (множественные) парадигмы.