Зачем нам нужно что-то большее, чем HTTP GET, PUT, POST?

Question

Какова практическая польза от использования HTTP GET, PUT, DELETE, POST, HEAD? Почему бы не сосредоточиться на их поведенческих преимуществах (безопасности и идемпотентности), забыть их имена и использовать GET, PUT или POST в зависимости от того, какое поведение мы хотим?

Почему бы нам не использовать только GET, PUT и POST (и отбрасывать HEAD, DELETE)?

Answer 1

Подход [REST] [1] использует POST, GET, PUT и DELETE для реализации правил CRUD для веб-ресурса. Это простой и удобный способ выставлять объекты на запросы в Интернете. Это веб-сервисы без накладных расходов.

Просто чтобы прояснить смысловые различия. Каждая операция довольно различна. Суть в том, чтобы иметь хорошие HTTP-методы, которые имеют четкое и понятное значение.

POST создает новые объекты. URI не имеет ключа; он принимает тело сообщения, которое определяет объект. Вставка SQL. [ Редактировать Хотя у POST нет технической причины не иметь ключа, ребята из REST настоятельно рекомендуют, чтобы у POST было отдельное значение как CREATE, но у него не должно быть ключа.]

GET извлекает существующие объекты. URI может иметь ключ, зависит от того, выполняете ли вы одиночный GET или список GET. SQL Select

PUT обновляет существующий объект. URI имеет ключ; Он принимает тело сообщения, которое обновляет объект. Обновление SQL.

УДАЛИТЬ удаляет существующий объект. У URI есть ключ. SQL Delete.

Можете ли вы обновить запись с помощью POST вместо PUT? Не без внесения некоторой двусмысленности. Глаголы должны иметь однозначные последствия. Кроме того, POST URI не имеют ключа, где PUT должен иметь ключ.

Когда я отправлю сообщение, я ожидаю, что 201 СОЗДАН. Если я не понимаю, что-то не так. Точно так же, когда я ставлю, я ожидаю 200 ОК. Если я не понимаю, что-то не так.

Полагаю, вы могли бы настаивать на некоторой двусмысленности, когда POST выполняет POST или PUT. URI должен быть другим; также связанное сообщение может быть другим. Как правило, REST люди берут свое начало от SQL, где INSERT и UPDATE - это разные глаголы.

Можно сделать так, чтобы UPDATE вставлял, если запись не существует, или обновлял, если запись существует. Однако проще, если UPDATE означает UPDATE, а неудача обновления означает, что что-то не так. Тайный откат к INSERT делает операцию неоднозначной.

Если вы не создаете интерфейс RESTful, то обычно используется только GET и POST для извлечения и создания / обновления. Распространены различия в URI или в содержании сообщения, чтобы различать POST и PUT, когда пользователь нажимает кнопку «Отправить» в форме. Однако он не очень чистый, потому что ваш код должен определить, находитесь ли вы в POST = create case или POST = update case.

Answer 2

POST не имеет гарантий безопасности или идемпотентности . Это одна из причин, по которой PUT и DELETE - оба PUT и DELETE являются идемпотентными (то есть 1 + N одинаковых запросов имеют тот же конечный результат, что и 1 запрос).

PUT используется для установки состояния ресурса по заданному URI. Когда вы отправляете запрос POST к ресурсу с определенным URI, этот ресурс не должен быть замененным содержимым. Самое большее, это должно быть добавлено к. Вот почему POST не идемпотентен - в случае добавления POSTS каждый запрос будет добавляться к ресурсу (например, каждый раз публиковать сообщение new на дискуссионном форуме).

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

HEAD используется, если все, что вас волнует, это заголовки запроса GET, и вы не хотите тратить пропускную способность на фактический контент. Это приятно иметь.

Answer 3

Зачем нам нужно больше, чем POST? Он позволяет передавать данные в обоих направлениях, так зачем же нужен GET? Ответ в основном такой же, как и на ваш вопрос. Стандартизируя основные ожидания различных методов, другие процессы могут лучше знать, что делать.

Например, промежуточные прокси-серверы могут иметь больше шансов сделать правильную вещь.

Подумайте, например, о HEAD. Если прокси-сервер знает, что означает HEAD, он может обработать результат предыдущего запроса GET, чтобы предоставить правильный ответ на запрос HEAD. И он может знать, что POST, PUT и DELETE не должны кэшироваться.

Answer 4

Никто не опубликовал ответ, который я искал, поэтому я постараюсь суммировать баллы самостоятельно.

Раздел 8 «RESTful Web Services» раздела «Перегрузка POST» гласит: «Если вы хотите вообще обходиться без PUT и DELETE, совершенно RESTful представляет безопасные операции над ресурсами через GET, а все другие операции через перегруженный POST. это нарушает мою ресурсно-ориентированную архитектуру, но соответствует менее строгим правилам REST. "

Короче говоря, замена PUT / DELETE на POST усложняет чтение API, а вызовы PUT / DELETE больше не являются идемпотентными .

Answer 5

Одним словом:

идемпотентность

В нескольких словах:

GET = безопасно + идемпотент

PUT = идемпотент

DELETE = идемпотент

POST = ни безопасно, ни идемпотентно

«Идемпотент» просто означает, что вы можете делать это снова и снова, и он всегда будет делать одно и то же.

Вы можете переиздавать запрос PUT (обновление) или DELETE столько раз, сколько захотите, и он будет иметь одинаковый эффект каждый раз, однако желаемый эффект изменит ресурс, поэтому он не считается «безопасным».

POST-запрос должен создавать новый ресурс с каждым запросом, то есть эффект будет отличаться каждый раз. Поэтому POST не считается безопасным или идемпотентным.

Такие методы, как GET и HEAD, являются просто операциями чтения и поэтому считаются «безопасными», а также идемпотентными.

Это на самом деле довольно важная концепция, поскольку она обеспечивает стандартный / согласованный способ интерпретации HTTP-транзакций; это особенно полезно в контексте безопасности.

Answer 6

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
<b>X-Fry: That's a chick show. I prefer programs of the genre: World's Blankiest Blank.</b>
Cache-Control: private
Pragma: private
Connection: close
Content-Type: text/html; charset=iso-8859-1

Для cURL , -I - это опция для выполнения запроса HEAD. Чтобы получить текущую дату и время данного сервера, просто наберите

curl -I $server | grep ^Date

Answer 7

Не все хостеры не поддерживают PUT, DELETE.

Я задал этот вопрос, в идеальном мире у нас были бы все глаголы, но ....:

Веб-службы RESTful и HTTP-глаголы

Answer 8

Существуют http-расширения, такие как WebDAV, которые требуют дополнительных функциональных возможностей.

http://en.wikipedia.org/wiki/WebDAV

Answer 9

GET, PUT, DELETE и POST - пережитки эпохи, когда второкурсники считали, что веб-страницу можно сократить до нескольких принципов высокого уровня.

В настоящее время большинство веб-страниц являются составными объектами, которые содержат некоторые или все эти примитивные операции. Например, на странице могут быть формы для просмотра или обновления информации о клиенте, которая может охватывать несколько таблиц.

Я обычно использую $ _REQUEST [] в php, не особо заботясь о том, как информация поступила. Я бы предпочел использовать методы GET или PUT, основанные на эффективности, а не на основных (множественных) парадигмах.

Answer 10

См. Следующую ссылку для наглядного примера. Также предлагается один из способов использования http-метода OPTIONS, который здесь еще не обсуждался.