Протокол передачи гипертекста (HTTP) - это основа жизни в Интернете. Он используется каждый раз при передаче документа или в запросе AJAX . Но HTTP на удивление мало известен некоторым веб-разработчикам.
В этом введении мы познакомимся с принципами разработки REST, лежащими в основе HTTP и использованию их мощи для создания интерфейсов, которые могут выполняться практически с любого устройства или операционной системы.
Переизданный урок
Каждые несколько недель мы пересматриваем некоторые из любимых сообщений наших читателей за всю историю сайта. Этот урок впервые был опубликован в ноябре 2010 года.
Почему REST?
REST - простой способ организации взаимодействия между независимыми системами.
REST - простой способ организации взаимодействия между независимыми системами. Он пользуется популярностью с 2005 года и вдохновляет дизайн сервисов, таких как API Twitter. Благодаря тому, что REST обеспечивает взаимодействие с такими разнообразными клиентами, как мобильные телефоны и другие веб-сайты. Теоретически, REST не привязан к сети, но почти всегда реализован как таковой и был вдохновлен HTTP. В результате REST можно использовать везде, где возможен HTTP.
Альтернативой является создание относительно сложных соглашений поверх HTTP. Часто это принимает форму новых XML-языков. Самый яркий пример - SOAP . Вам нужно выучить совершенно новый набор соглашений, но вы никогда не используете HTTP в полную силу. Поскольку REST был вдохновлён HTTP и играет на его сильные стороны, это лучший способ узнать, как работает HTTP.
После первоначального обзора мы рассмотрим каждый из строительных блоков HTTP: URL-адреса, HTTP-команды и коды ответов. Мы также рассмотрим, как использовать их в RESTful. Попутно мы проиллюстрируем теорию примером приложения, которое имитирует процесс отслеживания данных, связанных с клиентами компании через веб-интерфейс.
HTTP
HTTP - это протокол, который позволяет отправлять документы в Интернете.
HTTP - это протокол, который позволяет отправлять документы в Интернете. Протокол - это набор правил, определяющих, какие сообщения можно обменивать, и какие сообщения являются подходящими ответами для других. Другим распространенным протоколом является POP3, который вы можете использовать для извлечения электронной почты на вашем жёстком диске.
В HTTP есть две разные роли: сервер и клиент. Как правило, клиент всегда инициирует разговор; сервер отвечает. HTTP основан на тексте; то есть сообщения по сути являются битами текста, хотя тело сообщения может также содержать другие носители. Использование текста позволяет легко отслеживать обмен HTTP.
HTTP-сообщения состоят из заголовка и тела. Тело часто может оставаться пустым; оно содержит данные, которые вы хотите передать по сети, чтобы использовать их в соответствии с инструкциями в заголовке. Заголовок содержит метаданные, например информацию о кодировке; но, в случае запроса, он также содержит важные HTTP-методы. В стиле REST вы обнаружите, что данные заголовка часто более значимы, чем тела.
Шпионство HTTP на работе
Если вы используете Chrome Developer Tools или Firefox с расширением Firebug , щелкните на панели Net и установите его в enabled . После этого у вас будет возможность просматривать информацию о HTTP-запросах по мере вашего поиска. Например:
Другим полезным способом ознакомиться с HTTP является использование выделенного клиента, такого как cURL.
GET
GET - это самый простой тип HTTP-запроса; которым браузер пользуется каждый раз, когда вы нажимаете ссылку или вводите URL-адрес в адресную строку. Он инструктирует сервер передавать клиенту данные, идентифицированные URL-адресом. Никогда не последует изменений данных на стороне сервера в результате запроса GET . В этом смысле GET -запрос доступен только для чтения, но, конечно, как только клиент получит данные, он может самостоятельно выполнять любые операции с ними, например, форматировать для отображения.
PUT
Запрос PUT используется, когда вы хотите создать или обновить ресурс, указанный URL-адресом. Например,
PUT /clients/robin
может создать клиента с именем Robin на сервере. Вы заметите, что REST полностью независим от бэкэнда; в запросе нет ничего, что информирует сервер о том, как данные должны создаваться - просто так должно быть. Это позволяет вам легко менять базовую технологию по необходимости. Запросы PUT содержат данные для использования при обновлении или создании ресурса в body. В cURL вы можете добавить данные в запрос с помощью -d .
Curl -v -X PUT -d "some text"
DELETE
DELETE должен выполнять противоположное PUT ; его следует использовать, если вы хотите удалить ресурс, указанный URL-адресом запроса.
Curl -v -X DELETE /clients/anne
Это приведёт к удалению всех данных, связанных с ресурсом, идентифицированных /clients/anne .
POST
POST используется, когда обработка, которую вы хотите выполнить на сервере, должна повторяться, если запрос POST повторяется (то есть, они не являются идемпотентными , подробнее об этом ниже). Кроме того, POST -запросы должны вызывать обработку body запроса как подчинённого URL-адреса, который вы отправляете.
Проще говоря:
POST /clients/
не должен вызывать изменение ресурса в /clients/ сам, но ресурс URL начинается с него /clients/ . Например, он может добавить в список нового клиента, с id , сгенерированным сервером.
/clients/some-unique-id
Запросы PUT легко используются вместо запросов POST и наоборот. Некоторые системы используют только один, некоторые используют POST для создания операций и PUT для операций обновления (поскольку с запросом PUT вы всегда указываете полный URL-адрес), некоторые используют POST для обновлений и PUT для создания.
Часто запросы POST используются для запуска операций на сервере, которые не вписываются в парадигму Create/Update/Delete ; но это, однако, выходит за рамки REST . В нашем примере мы будем полностью придерживаться PUT .
Классификация методов HTTP
Безопасные и небезопасные методы:
безопасными являются методы, которые никогда не изменяют ресурсы. Единственными безопасными методами, из четырёх перечисленных выше, является GET . Другие небезопасны, так как они могут привести к модификации ресурсов.
Idempotent методы:Эти методы достигают того же результата, независимо от того, сколько раз запрос повторяется: это GET , PUT и DELETE . Единственным неидемпотентным методом является POST . PUT и DELETE , считающиеся идемпотентами, могут быть неожиданными, хотя, на самом деле, это довольно легко объяснить: повторение метода PUT с точно таким же body должно модифицировать ресурс таким образом, чтобы он оставался идентичным описанному в предыдущем запросе PUT: ничего не изменится! Аналогичным образом, нет смысла дважды удалять ресурс. Из этого следует, что независимо от того, сколько раз запрос PUT или DELETE повторяется, результат должен быть таким же, как если бы это было сделано только один раз.
Помните : именно вы, программист, в конечном счете решаете, что происходит, когда используется определённый HTTP-метод. В реализациях HTTP нет ничего, что автоматически приведёт к созданию ресурсов, их перечислению, удалению или обновлению. Вы должны быть осторожны, чтобы правильно применять HTTP-протокол и вводить эту семантику самостоятельно.
Представительства
HTTP-клиент и HTTP-сервер обмениваются информацией о ресурсах, определённых URL-адресами.
Мы можем суммировать то, что мы узнали до сих пор, следующим образом: HTTP-клиент и HTTP-сервер обмениваются информацией о ресурсах, определённых URL-адресами.
Мы говорим, что запрос и ответ содержат представление ресурса. Под представлением мы подразумеваем информацию в определённом формате о состоянии ресурса или о том, каким это состояние должно быть в будущем. Оба, и header, и body - являются частями представления.
Заголовки HTTP, содержащие метаданные, жёстко определяются спецификацией HTTP; они могут содержать только простой текст и должны быть отформатированы определённым образом.
Тело может содержать данные в любом формате, и именно здесь видна сила HTTP. Вы знаете, что можете отправлять простой текст, изображения, HTML и XML на любом человеческом языке. Через метаданные запроса или различные URL-адреса вы можете выбирать между различными представлениями для одного и того же ресурса. Например, вы можете отправить веб-страницу в браузеры и JSON в приложения.
HTTP-ответ должен указывать тип содержимого body. Это делается в заголовке, в поле Content-Type ; например:
Content/Type: application/json
Для простоты наше приложение только отправляет JSON туда и обратно, но приложение должно быть спроектировано таким образом, чтобы вы могли легко изменять формат данных, чтобы адаптироваться для разных клиентов или предпочтений пользователя.
Библиотеки клиента HTTP
cURL - это, чаще всего, HTTP-решение для PHP-разработчиков.
Чтобы поэкспериментировать с различными методами запроса, вам нужен клиент, который позволит указать, какой метод использовать. К сожалению, формы HTML не подходят для счёта, так как они позволяют делать только запросы GET и POST. В реальной жизни API-интерфейсы доступны программно через отдельное клиентское приложение или через JavaScript в браузере.
Именно поэтому в дополнение к серверу важно иметь хорошие возможности HTTP-клиента на выбранном вами языке программирования.
Очень популярная клиентская HTTP-библиотека, опять же, cURL. Вы уже были ознакомлены с командой cURL ранее в этом уроке. CURL включает в себя как автономную программу командной строки, так и библиотеку, которая может использоваться различными языками программирования. В частности, cURL является, чаще всего, идеальным решением HTTP-клиента для разработчиков PHP. Другие языки, такие как Python, предлагают больше собственных клиентских HTTP-библиотек.
Настройка примера приложения
Я хочу показать как можно более низкий уровень функциональности.
Наш пример PHP-приложения чрезвычайно тощ. Я хочу выставить как можно более низкоуровневую функциональность, без какой-либо магии framework . Я также не хотел использовать настоящий API, например, Twitter, потому что они могут неожиданно меняться, вам нужно настроить аутентификацию, что может быть проблемой и вы не сможете изучить реализацию.
Чтобы запустить пример приложения, вам необходимо установить PHP5 и веб-сервер с механизмом для запуска PHP. Текущая версия должна быть не ниже версии 5.2, чтобы иметь доступ к функциям json_encode () и json_decode () .
Что касается серверов, наиболее распространенным вариантом является Apache с mod_php , но вы можете использовать любые альтернативы, которые вам удобны. Существует пример конфигурации Apache, который содержит правила перезаписи, которые помогут вам быстро настроить приложение. Все запросы к любому URL, начиная с /clients/, должны быть направлены в наш файл server.php .
В Apache вам нужно включить mod_rewrite и поместить прилагаемую конфигурацию mod_rewrite где-нибудь в вашей конфигурации Apache или в ваш файл .htacess . Таким образом, server.php будет отвечать на все запросы, поступающие с сервера. То же самое должно быть достигнуто с Nginx, или с любым другим сервером, который вы решите использовать.
Как работает пример приложения
Есть два ключа по обработке запросов REST. Первый ключ - инициировать различную обработку, в зависимости от метода HTTP, даже когда URL-адреса одинаковы. В PHP в глобальном массиве $ _SERVER есть переменная, которая определяет, какой метод был использован для выполнения запроса:
$_SERVER["REQUEST_METHOD"]
Эта переменная содержит имя метода в виде строки, например " GET ", " PUT " и далее.
Другой ключ - узнать, какой URL был запрошен. Для этого мы используем другую стандартную переменную PHP:
$_SERVER["REQUEST_URI"]
Эта переменная содержит URL-адрес, начинающийся с первой косой черты. Например, если имя хоста - " example.com ", " http://example.com/ " вернётся " / ", как " http://example.com/test/ " вернётся " /test/ ".
Давайте сначала попытаемся определить, какой URL-адрес был вызван. Мы рассматриваем только URL-адреса, начинающиеся с " clients ". Все остальные недействительны.
$resource = array_shift($paths); if ($resource == "clients") { $name = array_shift($paths); if (empty($name)) { $this->handle_base($method); } else { $this->handle_name($method, $name); } } else { // We only handle resources under "clients" header("HTTP/1.1 404 Not Found"); }
У нас есть два возможных результата:
- Ресурс - это клиенты, и в этом случае мы возвращаем полный список
- Существует еще один идентификатор
Если есть ещё один идентификатор, мы предполагаем, что это имя клиента, и, опять же, перенаправляем его в другую функцию, в зависимости от method . Мы используем оператор switch , которого следует избегать в реальном приложении:
Switch($method) { case "PUT": $this->create_contact($name); break; case "DELETE": $this->delete_contact($name); break; case "GET": $this->display_contact($name); break; default: header("HTTP/1.1 405 Method Not Allowed"); header("Allow: GET, PUT, DELETE"); break; }
Коды ответов
Коды ответа HTTP стандартизируют способ информирования клиента о результате его запроса.
Вы могли заметить, что пример приложения использует PHP header() , передавая некоторые странные строки в качестве аргументов. Функция header() печатает HTTP headers и гарантирует, что они отформатированы соответствующим образом. Заголовки должны быть первым в ответе, поэтому не стоит выводить что-либо ещё до того, как вы закончите с заголовками. Иногда ваш HTTP-сервер может быть настроен для добавления других заголовков в дополнение к тем, которые вы указали в коде.
Сервер должен вернуть наиболее подходящий код ответа HTTP; таким образом клиент может попытаться исправить свои ошибки, если они есть. Большинство людей знакомы с распространенным кодом ответа 404 Not Found , однако есть много более доступных, в соответствии множеству ситуаций.
Имейте в виду, что значение кода ответа HTTP не является чрезвычайно точным; это следствие того, что HTTP сам по себе довольно общий. Вы должны попытаться найти код ответа, который наиболее точно соответствует ситуации. Но и не слишком переживайте, если не сможете найти точное соответствие.
Вот несколько HTTP-кодов ответа, которые часто используются с REST:
200 OK
Этот код ответа указывает, что запрос был успешным.
201 Created
Это означает, что запрос был успешным и был создан ресурс. Он используется в случае успеха запроса PUT или POST .
400 Bad Request
Запрос был утерян. Это происходит особенно с запросами POST и PUT , когда данные не проходят валидацию или находятся в неправильном формате.
404 Not Found
Этот ответ указывает, что необходимый ресурс не найден. Обычно это относится ко всем запросам, которые указывают на URL-адрес без соответствующего ресурса.
401 Unauthorized
Эта ошибка означает, что вам необходимо выполнить проверку подлинности перед доступом к ресурсу.
405 Method Not Allowed
Используемый метод HTTP не поддерживается для этого ресурса.
409 Conflict
Это указывает на конфликт. Например, вы используете запрос PUT для создания одного и того же ресурса дважды.
500 Internal Server Error
Когда всё остальное терпит неудачу; как правило, ответ 500 используется, когда обработка завершается неудачно из-за непредвиденных обстоятельств на стороне сервера, что вызывает ошибку сервера.
Выполнение образца приложения
Давайте начнем с простого извлечения информации из приложения. Нам нужны детали клиента, " jim ", поэтому давайте отправим простой запрос GET на URL этого ресурса:
Curl -v http://localhost:80/clients/jim
Это отобразит полные сообщения headers. Последней строкой ответа будет body сообщения; в этом случае это будет JSON, содержащий адрес Jim (помните, что пропуск имени метода приведет к GET -запросу, а также замените localhost: 80 на имя сервера и порт, который вы используете).
Затем мы можем получить информацию для всех клиентов одновременно:
Curl -v http://localhost:80/clients/
Чтобы создать нового клиента с именем Paul ...
Curl -v -X PUT http://localhost:80/clients/paul -d "{"address":"Sunset Boulevard" }
и вы получите список всех клиентов, содержащих Paul в качестве подтверждения.
Наконец, чтобы удалить клиента:
Curl -v -X DELETE http://localhost:80/clients/anne
Вы обнаружите, что возвращённый JSON больше не содержит никаких данных об Anne.
Если вы пытаетесь получить несуществующего клиента, например:
Curl -v http://localhost:80/clients/jerry
Вы получите ошибку 404, в то время как при попытке создать уже существующего клиента:
curl -v -X PUT http://localhost:80/clients/anne
вместо этого получите ошибку 409.
Заключение
В общем, чем меньше предположений за пределами HTTP вы делаете, тем лучше.
Важно помнить, что HTTP был задуман для взаимодействия между системами, которые ничто не разделяет, кроме понимания протокола. В целом, чем меньше допущений за пределами HTTP вы делаете, тем лучше: это позволяет широкому кругу программ и устройств получать доступ к вашему API.
Я использовал PHP в этом уроке, потому что это, скорее всего, язык, наиболее знакомый читателям Nettuts +. Тем не менее, PHP, хотя и предназначен для Интернета, вероятно, не самый лучший язык для работы при REST-способе, поскольку он обрабатывает запросы PUT совсем иначе, чем GET и POST .
Помимо PHP, вы можете принять во внимание следующее:
- Различные Ruby frameworks (Rails и Sinatra)
- В Python есть отличная поддержка REST. Должны работать Plain Django и WebOb , или Werkzeug .
- node.js отлично поддерживает REST
Среди приложений, которые пытаются придерживаться принципов REST, классическим примером является Atom Publishing Protocol , хотя на самом деле он не используется слишком часто на практике. За современным приложением, основанным на философии использования HTTP в полной мере, обратитесь к Apache CouchDB .
Насколько я понимаю все это, то, если сравнить PUT и POST операциями в MySQL, то POST - это INSERT, а PUT - UPDATE or INSERT
Расмотрим на примере форума. В нём есть темы и сообщения. Мы делаем запросы в тему hello
POST /topic/hello?message = Здесь POST /topic/hello?message = был POST /topic/hello?message = Вася
Первый запрос создаст (INSERT ) тему hello с сообщением "Здесь", остальные два запроса тоже создадут (INSERT ) новые сообщения в теме. В результате у нас получится, что тема hello содержит: Здесь был Вася.
PUT /topic/hello?message = Здесь PUT /topic/hello?message = был PUT /topic/hello?message = Вася
Первый запрос создаст (INSERT ) тему hello с сообщением "Здесь", остальные два запроса обновят (UPDATE ) сообщение в теме. В результате у нас получится, что тема hello содержит: Вася.
Идемпотентность PUT здесь проявляется в том, что количество сообщений в базе при последующих операциях остаётся неизменным . Касательно ссылок - карта сайта будет оставаться неизменной. Будет обновляться лишь содержимое тем.
или: каждый запрос POST /article/hello будет создавать новую главу в статье hello. Первый запрос создаст саму статью.
каждый запрос PUT /article/hello будет обновлять ЕДИНСТВЕННУЮ главу в статье hello. Первый запрос создаст саму статью.
Вот, что нам должен возвращать GET, если мы делали POST
GET /topic/hello 201 Здесь был Вася
В этом случае у нас также будут доступны и эти URI
GET /topic/hello/1 201 Здесь GET /topic/hello/2 201 был GET /topic/hello/3 201 Вася
Вот, что нам должен вернуть GET, если мы делали PUT
GET /topic/hello 201 Вася
В этом случае у нас будет доступна только одна URI
GET /topic/hello/1 201 Вася GET /topic/hello/2 404 GET /topic/hello/3 404
EXAMPLE #2 Пример с пользователями.
POST /user/eugen?age=7 POST /user/eugen?age=10 POST /user/eugen?age=5
Создаст 3 пользователя с именем eugen и возрастом 7, 10, 5, соответственно.
PUT /user/eugen?age=7 PUT /user/eugen?age=10 PUT /user/eugen?age=5
Будет создан только один пользователь с именем eugen с возрастом 5
Другими словами: PUT обязан обновлять запись, если данные уже есть
Отсюда и Ваш пример String userId = this.request["USER_ID"]; с сохранением значения в переменной. Сколько раз вы бы не ложили (PUT ) значения в переменную - переменная всегда будет одна.
Отсюда родился EXAMPLE #3
Не знаю на сколько эта аналогия верна, но думаю это утверждение будет верно:
POST: push $variable, value; -- в итоге массив значений PUT: $variable = value; -- в итоге одно значение
в случае POST, вред, который может возникнут, это переполнится память сервера. В случае PUT - никакого вреда нет, только такты забираются;-)
Кстати, вот нашел хороший ресурс, по поводу безопасности и идемпотентности
612
HTTP PUT:
PUT помещает файл или ресурс в определенный URI, и именно на этом URI. Если в этом URI уже есть файл или ресурс, PUT заменяет этот файл или ресурс. Если там нет файла или ресурса, PUT создает его. PUT - idempotent , но, как ни парадоксально, ответы PUT не подлежат кэшированию.
HTTP POST:
POST отправляет данные на конкретный URI и ожидает ресурс на том, что URI для обработки запроса. Веб-сервер в этот момент может определить, что делать с данными в контексте указанного ресурса. Метод POST не равен idempotent , однако ответы POST : кэшируются, если сервер устанавливает соответствующие заголовки Cache-Control и Expires.
Официальный HTTP RFC определяет POST быть:
- Аннотация существующих ресурсов;
- Публикация сообщения на доске объявлений, в новостной группе, списке рассылки, или аналогичной группе статей;
- Предоставление блока данных, таких как результат отправки формы, в процесс обработки данных;
- Расширение базы данных с помощью операции добавления.
Разница между POST и PUT:
Сам RFC объясняет разницу ядра:
Фундаментальное различие между POST и PUT запросов отражено в различное значение Request-URI. URI в запросе POST идентифицирует ресурс, который будет обрабатывать заключенный объект. Этот ресурс может быть принимающим данные процессом, шлюзом к другому протоколу или отдельным объектом, который принимает аннотации. В отличии от этого, URI в запросе PUT идентифицирует объекта, включенный в запросе - агент пользователя знает, что URI является предназначен и сервер НЕ ДОЛЖЕН попытки применить запрос к некоторым другому ресурсу. Если сервер желает, чтобы запрос был применен к другому URI , он ДОЛЖЕН отправить 301 (перемещенный постоянный) ответ; пользовательский агент МОЖЕТ затем сделать своим собственным решением относительно того, перенаправить запрос или нет.
Используя правильный метод, несвязанные в стороне:
Я получаю в последнее время довольно раздражает популярное заблуждение веб-разработчиков, что POST используется для создания ресурса, а PUT используется для обновления/изменения.
Если вы посмотрите на странице 55 RFC 2616 («Протокол передачи гипертекста - HTTP/1.1»), Section 9.6 («PUT»), вы увидите, что PUT на самом деле для:
Метод PUT запрашивает, чтобы закрытый объект хранился в запрошенном Request-URI.
Там также удобный пункт, чтобы объяснить разницу между POST и PUT:
Фундаментальное различие между POST и PUT запросов находит свое отражение в другом значении Request-URI. URI в запросе POST идентифицирует ресурс, который будет обрабатывать заключенный объект. Этот ресурс может быть процессом принятия данных, шлюзом к другому протоколу или отдельным объектом, который принимает аннотации. Напротив, URI в запросе PUT идентифицирует объект, заключенный с запросом - пользовательский агент знает, что такое URI, и сервер НЕ ДОЛЖЕН пытаться применить запрос к другому ресурсу.
В нем ничего не говорится о различии между обновлением/созданием, потому что это не то, о чем речь. Речь идет о разнице между этим:
Obj.set_attribute(value) # A POST request.
Obj.attribute = value # A PUT request.
Поэтому, пожалуйста, остановить распространение этого популярного заблуждения. Прочтите свои RFC.
9
Это кажется бесполезным грубым и педантичным менее полезным способом. В примере PUT, который вы цитируете, новый объект в RESTful api является «новой» записью и доступен в этом месте. Не вызывает сомнений, является ли хороший выбор дизайна, позволяющий подменям быть такими, как это (я думаю, что это не идеальный вариант), но даже если бы вы использовали подвид, чтобы нападать на большую полезную информацию. В большинстве случаев описание, как обычно говорится, является отличным заявлением о содержании RFC, суммированном и заявлении обычной и обычной практики. Кроме того, вам не будет больно быть вежливым. - tooluser 06 апр. 15 2015-04-06 23:49:56
60
1) GET: - Используется, когда клиент запрашивает ресурс на веб-сервере.
2) HEAD: - Используется, когда клиент запрашивает некоторую информацию о ресурсе, но не запрашивает сам ресурс.
3) POST: - Используется, когда клиент отправляет информацию или данные на сервер, например, заполняя онлайн-форму (т. Е. Отправляет на веб-сервер большое количество сложных данных).
4) PUT: - Используется, когда клиент отправляет заменяющий документ или загружает новый документ на веб-сервер под URL-адресом запроса.
5) УДАЛИТЬ: - Используется, когда клиент пытается удалить документ с веб-сервера, идентифицированный URL-адресом запроса.
6) TRACE: - Используется, когда клиент запрашивает доступные прокси или промежуточные серверы, изменяющие запрос, чтобы объявить себя.
7) ОПЦИИ: - Используется, когда клиент хочет определить другие доступные методы для извлечения или обработки документа на веб-сервере.
8) CONNECT: - Используется, когда клиент хочет установить прозрачное соединение с удаленным хостом, как правило, для обеспечения SSL-шифрованной связи (HTTPS) через HTTP-прокси.
15
15 ответов
HTTP PUT:
PUT помещает файл или ресурс в определенный URI и точно в этот URI. Если в этом URI уже есть файл или ресурс, PUT заменяет этот файл или ресурс. Если там нет файла или ресурса, PUT создает его. PUT idempotent , но парадоксально ответы PUT не кэшируемы.
HTTP POST:
POST отправляет данные в определенный URI и ожидает, что ресурс в этом URI обрабатывает запрос. Веб-сервер в этот момент может определить, что делать с данными в контексте указанного ресурса. Метод POST не idempotent , однако ответы POST могут быть кэшируемыми, если сервер устанавливает соответствующие заголовки Cache-Control и Expires.
Официальный HTTP RFC определяет POST как:
- Аннотация существующих ресурсов;
- Размещение сообщения на доске объявлений, в новостной группе, в списке рассылки, или аналогичная группа статей;
- Предоставление блока данных, например, результата отправки формы, к процессу обработки данных;
- Расширение базы данных с помощью операции добавления.
Разница между POST и PUT:
Сам RFC объясняет основную разницу:
Основное различие между Запросы POST и PUT отражены в различный смысл Request-URI. URI в запросе POST идентифицирует ресурс, который будет обрабатывать закрытую сущность. Что ресурсом может быть прием данных процесс, шлюз для некоторых других протокол или отдельный объект, который принимает аннотации. Напротив, URI в запросе PUT идентифицирует объект, прилагаемый к запросу - пользовательский агент знает, что такое URI и сервер НЕ ДОЛЖЕН попытка применить запрос к другой ресурс. Если сервер желает что запрос будет применен к другой URI, он ДОЛЖЕН отправить 301 (перемещенный постоянный) ответ; пользовательский агент МОЖЕТ затем сделать его собственное решение относительно того, следует ли перенаправить запрос.
Использование правильного метода, не связанного в стороне:
Только семантика.
Предполагается, что HTTP PUT принимает тело запроса, а затем сохраняет его на ресурсе, идентифицированном URI.
HTTP POST является более общим. Предполагается инициировать действие на сервере. Это действие может состоять в том, чтобы сохранить тело запроса в ресурсе, идентифицированном URI, или это может быть другой URI, или это может быть другое действие.
PUT , например . Помещенный в URI влияет именно на этот URI. POST для URI может вообще иметь какой-либо эффект.
Чтобы привести примеры ресурсов стиля REST:
"POST/books" с кучей информации о книге может создать новую книгу и ответить новым URL-адресом, идентифицирующим эту книгу: "/books/5".
"PUT/books/5" придется либо создать новую книгу с идентификатором 5, либо заменить существующую книгу с идентификатором 5.
В стиле non-resource POST можно использовать практически для всего, что имеет побочный эффект. Еще одно отличие состоит в том, что PUT должен быть идемпотентным - несколько PUT одинаковых данных для одного и того же URL-адреса должны быть точными, если несколько POST могут создавать несколько объектов или что-то, что делает ваше POST-действие.
1) GET: - используется, когда клиент запрашивает ресурс на веб-сервере.
2) HEAD: - используется, когда клиент запрашивает некоторую информацию о ресурсе, но не запрашивает сам ресурс.
3) POST: - используется, когда клиент отправляет информацию или данные на сервер, например, заполняя онлайн-форму (т.е. отправляет большое количество сложных данных на веб-сервер).
4) PUT: - Используется, когда клиент отправляет заменяющий документ или загружает новый документ на веб-сервер под URL-адресом запроса.
5) DELETE: - Используется, когда клиент пытается удалить документ с веб-сервера, указанный URL-адресом запроса.
6) TRACE: - Используется, когда клиент просит доступные прокси или промежуточные серверы изменять запрос, чтобы объявить себя.
7) ОПЦИИ: - Используется, когда клиент хочет определить другие доступные методы для извлечения или обработки документа на веб-сервере.
8) CONNECT: - Используется, когда клиент хочет установить прозрачное соединение с удаленным хостом, как правило, для обеспечения SSL-шифрованной связи (HTTPS) через прокси-сервер HTTP.
Другие уже опубликовали отличные ответы, я просто хотел добавить, что с большинством языков, фреймворков и прецедентов вы будете иметь дело с POST много, гораздо чаще, чем PUT. К моменту, когда PUT, DELETE и т.д. Являются в основном пустяковыми вопросами.
Согласно RFC , разница между PUT и POST находится в URI запроса. URI, идентифицированный POST, определяет объект, который будет обрабатывать запрос POST. URI в запросе PUT включает объект в запрос. Таким образом, POST /v1/coffees/orders означает создание нового ресурса и возврат идентификатор для описания ресурса. Напротив, PUT /v1/coffees/orders/1234 означает обновление ресурса, идентифицированного " 1234 ", если оно существует; иначе создайте новый порядок и используйте URI orders/1234 , чтобы идентифицировать его.
PUT and POST can both be used to create or update methods. The usage of the method depends on the idempotent behavior expected from the method as well as the location of the resource to identify it.
POST считается чем-то вроде метода типа factory. Вы включаете данные с ним, чтобы создать то, что хотите, и все, что находится на другом конце, знает, что с ним делать. PUT используется для обновления существующих данных по указанному URL-адресу или для создания чего-то нового, когда вы знаете, что будет URI, и он еще не существует (в отличие от POST, который создаст что-то и вернет URL-адрес при необходимости).
В последнее время меня очень раздражает популярное заблуждение веб-разработчиков, что POST используется для создания ресурса, а PUT используется для обновления/изменения.
Если вы посмотрите на страницу 55 RFC 2616 ("Протокол передачи гипертекста - HTTP/1.1"), раздел 9.6 ("PUT"), вы увидите что PUT действительно для:
Метод PUT запрашивает, чтобы закрытый объект был сохранен в поставляемом Request-URI.
Theres также удобный абзац, чтобы объяснить разницу между POST и PUT:
Основное различие между запросами POST и PUT отражается в различном значении Request-URI. URI в запросе POST идентифицирует ресурс, который будет обрабатывать заключенный объект. Этот ресурс может быть процессом принятия данных, шлюзом к другому протоколу или отдельным объектом, который принимает аннотации. Напротив, URI в запросе PUT идентифицирует объект, заключенный с запросом - пользовательский агент знает, что такое URI, и сервер НЕ ДОЛЖЕН пытаться применить запрос к другому ресурсу.
В нем ничего не говорится о различии между обновлением/созданием, потому что это не о чем. О различии между этим:
Obj.set_attribute(value) # A POST request.
Obj.attribute = value # A PUT request.
Поэтому, пожалуйста, прекратите распространение этого популярного заблуждения. Прочтите свои RFC.
REST просит разработчиков использовать методы HTTP явно и таким образом, чтобы это соответствовало определению протокола. Этот базовый принцип проектирования REST устанавливает взаимно-однозначное сопоставление между операциями создания, чтения, обновления и удаления (CRUD) и методами HTTP. Согласно этому отображению:
Чтобы создать ресурс на сервере, используйте POST.
Чтобы получить ресурс, используйте GET.
Чтобы изменить состояние ресурса или обновить его, используйте PUT.
Чтобы удалить или удалить ресурс, используйте DELETE.
7 ответов
СООБЩЕНИЕ
HTTP.POST можно использовать, когда клиент отправляет данные на сервер, а сервер определяет URI для вновь созданного ресурса. Метод POST используется для запроса, чтобы исходный сервер принял объект, включенный в запрос, в качестве нового подчиненного ресурса, идентифицируемого Request-URI в строке запроса.
ПОЛОЖИЛ
HTTP.PUT может использоваться, когда клиент отправляет данные на сервер, и клиент определяет URI для вновь созданного ресурса. Метод PUT запрашивает, чтобы вложенный объект был сохранен под предоставленным Request-URI. Если Request-URI ссылается на уже существующий ресурс, вложенный объект СЛЕДУЕТ рассматривать как модифицированную версию, находящуюся на исходном сервере. Если Request-URI не указывает на существующий ресурс, и этот URI может быть определен как новый ресурс запрашивающим пользовательским агентом, сервер-источник может создать ресурс с этим URI.
PATCH
HTTP.PATCH может использоваться, когда клиент отправляет одно или несколько изменений, которые будут применены сервером. Метод PATCH запрашивает, чтобы набор изменений, описанный в объекте запроса, был применен к ресурсу, идентифицированному Request-URI. Набор изменений представлен в формате, называемом патч-документ.
Для получения дополнительной информации обратитесь к указанному ниже URL
Разница между PUT, POST, GET, DELETE и PATCH IN HTTP Глаголы:
Наиболее часто используемые HTTP-глаголы POST, GET, PUT, DELETE аналогичны операциям CRUD (Create, Read, Update and Delete) в базе данных. Мы указываем эти HTTP-глаголы в случае с капиталом . Итак, ниже показано сравнение между ними.
- create - POST
- читать - GET
- update - PUT
- delete - DELETE
PATCH: Предоставляет частичную модификацию ресурса. Если вам нужно обновить только одно поле для ресурса, вы можете использовать метод PATCH.
Замечания:
Поскольку POST, PUT, DELETE изменяет содержимое, тесты с помощью скрипача для приведенного ниже URL просто подражают обновлениям.
Он не удаляет и не изменяет фактически.
Мы можем просто просмотреть коды состояния, чтобы проверить, не возникают ли вставки, обновления, удаления.
1) ПОЛУЧИТЬ:
GET - это самый простой способ HTTP-запроса; тот, который браузеры используют при каждом нажатии ссылки или введите URL-адрес в адресную строку. Он инструктирует сервер передавать данные, идентифицированные по URL-адресу клиенту. Данные не должны изменяться на стороне сервера в результате запроса GET. В этом смысле запрос GET доступен только для чтения.
Ответ: вы получите ответ как:
"userId": 1, "id": 1, "title": "sunt aut...", "body": "quia et suscipit..."
В пути "счастливый" (или без ошибок) GET возвращает представление в XML или JSON и код ответа HTTP 200 (OK). В случае ошибки он чаще всего возвращает 404 (NOT FOUND) или 400 (BAD REQUEST).
2) POST:
Глагол POST в основном используется для создания новых ресурсов. В частности, он использовал для создания подчиненных ресурсов. То есть подчиняется другому (например, родительскому) ресурсу.
При успешном создании возвращайте HTTP-статус 201, возвращая заголовок Location с ссылкой на вновь созданный ресурс с HTTP-статусом 201.
Проверка с помощью Fiddler или PostMan: мы можем использовать скрипач для проверки ответа. Откройте скрипт и выберите вкладку Compose. Укажите глагол и URL-адрес, как показано ниже, и нажмите "Выполнить", чтобы проверить ответ.
Тело запроса:
данные: {title: "foo", body: "bar", userId: 1000, Id: 1000}
Ответ. Вы получите код ответа 201.
Если мы хотим проверить вставленную запись с Id = 1000, измените глагол Get и используйте тот же url и нажмите Execute.
Как было сказано ранее, указанный выше URL-адрес позволяет читать только чтения (GET), мы не можем читать обновленные данные в реальном времени.
PUT чаще всего используется для возможностей обновления , PUT-ing к известному URI ресурса с телом запроса, содержащим обновленное представление исходного ресурса.
Проверка с помощью Fiddler или PostMan: мы можем использовать скрипач для проверки ответа. Откройте скрипт и выберите вкладку Compose. Укажите глагол и URL-адрес, как показано ниже, и нажмите "Выполнить", чтобы проверить ответ.
Тело запроса:
data: {title: "foo", body: "bar", userId: 1, Id: 1}
Ответ. При успешном обновлении он возвращает 200 (или 204, если не возвращает какой-либо контент в теле) из PUT.
4) УДАЛИТЬ:
DELETE довольно легко понять. Он используется для удаления ресурса, идентифицированного с помощью URI.
При успешном удалении возвращайте HTTP-статус 200 (OK) вместе с телом ответа, возможно, представление удаленного элемента (часто требует слишком большой полосы пропускания) или завернутый ответ (см. "Возвращаемые значения" ниже). Либо это, либо вернуть статус HTTP 204 (NO CONTENT) без тела ответа. Другими словами, рекомендуемый ответ - статус 204 без тела, или ответ типа JSEND и статус HTTP 200.
Проверка с помощью Fiddler или PostMan: мы можем использовать скрипач для проверки ответа. Откройте скрипт и выберите вкладку Compose. Укажите глагол и URL-адрес, как показано ниже, и нажмите "Выполнить", чтобы проверить ответ.
Глагол: УДАЛИТЬ
Ответ. При успешном удалении он возвращает статус HTTP 200 (OK) вместе с телом ответа.
Пример между PUT и PATCH
ПОЛОЖИЛ
Если мне пришлось изменить свое имя, то отправьте запрос PUT для обновления:
{"first": "Nazmul", "last": "hasan"} Итак, здесь, чтобы обновить первое имя, нам нужно снова отправить все параметры данных.
Патч-запрос говорит, что мы будем отправлять только данные, которые нам нужно изменить без изменения или воздействия на другие части данных. Пример: если нам нужно обновить только первое имя, мы передаем только первое имя.
Для получения дополнительной информации см. Ссылки ниже:
PUT = заменить ПОЛНЫЙ РЕСУРС новым представлением
PATCH = заменить части исходного ресурса на значения, предоставленные И | ИЛИ другие части ресурса обновлены, которые вы предоставили (временные метки) И | ИЛИ обновили ресурсные эффекты другими ресурсами (отношениями)
GET/PUT - идемпотентный патч иногда может быть идемпотентным
То, что является идемпотентом - это означает, что если мы запускаем запрос несколько раз, это не должно влиять на его результат (тот же результат. Предположим, что корова беременна, и если мы разводим ее снова, то она не может быть беременна несколько раз).
get: -
просто получить. Получить данные с сервера и показать их пользователю
post: -
создать новый ресурс в базе данных. Это означает, что он добавляет новые данные. Это не идемпотент.
put: -
Создать новый ресурс, иначе добавить к существующему. Идемпотент, потому что он будет обновлять один и тот же ресурс каждый раз, и результат будет одинаковым. ех. - исходные данные
{ id:1 name:parth email:[email protected] }
- выполнить put-localhost/1 put email: [email protected]
patch
так что теперь пришел патч, запрос PATCH может быть иногда идемпотентным
Id:1 name:parth email:[email protected] }
Название патча: W
{ id:1 name:w email:[email protected] } HTTP Method GET yes POST no PUT yes PATCH no* OPTIONS yes HEAD yes DELETE yes
Приведенное ниже определение взято из примера из реального мира.
Примерный обзор
Для каждой клиентской информации мы храним идентификатор, чтобы найти эти клиентские данные, и мы отправим этот идентификатор клиенту для справки.
СООБЩЕНИЕ
- Если Клиент отправляет данные без идентификатора с использованием метода POST, мы сохраняем их и назначаем новый идентификатор.
- Если Клиент снова отправляет те же данные без идентификатора с помощью метода POST, мы сохраняем их и назначаем новый идентификатор.
- Примечание : дублирование разрешено здесь
ПОЛОЖИЛ
- Если Клиент отправляет данные с идентификатором, мы проверим, существует ли этот идентификатор. Если идентификатор существует, мы обновим данные, в противном случае мы создадим его и назначим новый идентификатор.
-
- Если Клиент отправляет данные с идентификатором, мы проверим, существует ли этот идентификатор. Если идентификатор существует, мы обновим данные, иначе мы сгенерируем исключение.
Примечание. В методе Put мы не генерируем исключение, если идентификатор не найден. Но в методе Patch мы генерируем исключение, если идентификатор не найден.
Дайте мне знать, если у вас есть какие-либо вопросы по вышеуказанному.
Вот разница между методами POST, PUT и PATCH протокола HTTP.
POST
Метод HTTP.POST всегда создает новый ресурс на сервере. Его не-идемпотентный запрос, т.е. Если пользователь обращается к тем же запросам 2 раза, он создаст новый новый ресурс, если нет ограничений.
http post method is like a INSERT query in SQL which always creates a new record in database.
Пример. Используйте метод POST для сохранения нового пользователя, заказа и т.д., когда серверный сервер решает идентификатор ресурса для нового ресурса.
PUT
В методе HTTP.PUT ресурс сначала идентифицируется из URL-адреса, и если он существует, то он обновляется, иначе создается новый ресурс. Когда целевой ресурс существует, он перезаписывает этот ресурс с полным новым телом. Это метод HTTP.PUT используется для СОЗДАНИЯ или ОБНОВЛЕНИЯ ресурса.
http put method is like a MERGE query in SQL which inserts or updates a record depending upon whether the given record exists.
Запрос PUT является idempotent, т.е. удары одних и тех же запросов дважды будут обновлять существующую запись (новая запись не создается). В методе PUT идентификатор ресурса определяется клиентом и указан в URL-адресе запроса.
Пример. Используйте метод PUT для обновления существующего пользователя или заказа.
PATCH
Метод HTTP.PATCH используется для частичных модификаций обновления ресурса, то есть дельта-обновления.
http patch method is like a UPDATE query in SQL which sets or updates selected columns only and not the whole row.
Пример. Вы можете использовать метод PATCH для обновления состояния заказа.
PATCH/api/users/40450236/order/10234557