HTTP (англ. HyperText Transfer Protocol - «протокол передачи гипертекста») - протокол прикладного уровня передачи данных (изначально - в виде гипертекстовых документов в формате HTML). Основой HTTP является технология «клиент-сервер», то есть предполагается существование потребителей (клиентов), которые инициируют соединение и посылают запрос, и поставщиков (серверов), которые ожидают соединения для получения запроса, производят необходимые действия и возвращают обратно сообщение с результатом. HTTP в настоящее время повсеместно используется во Всемирной паутине для получения информации с веб-сайтов.

HTTP используется также в качестве «транспорта» для других протоколов прикладного уровня, таких как SOAP, XML-RPC, WebDAV.

Основным объектом манипуляции в HTTP является ресурс, на который указывает URI (англ. Uniform Resource Identifier) в запросе клиента. Обычно такими ресурсами являются хранящиеся на сервере файлы, но ими могут быть логические объекты или что-то абстрактное. Особенностью протокола HTTP является возможность указать в запросе и ответе способ представления одного и того же ресурса по различным параметрам: формату, кодировке, языку и т. д. (В частности для этого используется HTTP-заголовок.) Именно благодаря возможности указания способа кодирования сообщения клиент и сервер могут обмениваться двоичными данными, хотя данный протокол является текстовым.

HTTP - протокол прикладного уровня, аналогичными ему являются FTP и SMTP. Обмен сообщениями идёт по обыкновенной схеме «запрос-ответ». Для идентификации ресурсов HTTP использует глобальные URI. В отличие от многих других протоколов, HTTP не сохраняет своего состояния. Это означает отсутствие сохранения промежуточного состояния между парами «запрос-ответ». Компоненты, использующие HTTP, могут самостоятельно осуществлять сохранение информации о состоянии, связанной с последними запросами и ответами (например, «куки» на стороне клиента, «сессии» на стороне сервера). Браузер, посылающий запросы, может отслеживать задержки ответов. Сервер может хранить IP-адреса и заголовки запросов последних клиентов. Однако сам протокол не осведомлён о предыдущих запросах и ответах, в нём не предусмотрена внутренняя поддержка состояния, к нему не предъявляются такие требования.

Преимущества

Данный протокол очень прост в реализации, хорошо расширяется благодаря внедрению собственных заголовков, добавляющие функциональности приложению, и которые будут игнорироваться другими приложениями, посчитавшими их неизвестными:

Простота. Протокол прост в реализации, что позволяет легко создавать клиентские приложения.

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

Распространённость. При выборе протокола HTTP для решения конкретных задач немаловажным фактором является его распространённость. Как следствие, это обилие различной документации по протоколу на многих языках мира, включение удобных в использовании средств разработки в популярные IDE, поддержка протокола в качестве клиента многими программами и обширный выбор среди хостинговых компаний с серверами HTTP.

Структура протокола

Каждое HTTP-сообщение состоит из трёх частей, которые передаются в указанном порядке:

Стартовая строка (англ. Starting line) - определяет тип сообщения;

Заголовки (англ. Headers) - характеризуют тело сообщения, параметры передачи и прочие сведения;

Тело сообщения (англ. Message Body) - непосредственно данные сообщения. Обязательно должно отделяться от заголовков пустой строкой.

Заголовки и тело сообщения могут отсутствовать, но стартовая строка является обязательным элементом, так как указывает на тип запроса/ответа. Исключением является версия 0.9 протокола, у которой сообщение запроса содержит только стартовую строку, а сообщения ответа только тело сообщения.

Стартовая строка

Стартовые строки различаются для запроса и ответа. Строка запроса выглядит так:

GET URI - для версии протокола 0.9.

Метод URI HTTP/Версия - для остальных версий.

Метод (англ. Method) - название запроса, одно слово заглавными буквами. В версии HTTP 0.9 использовался только метод GET, список запросов для версии 1.1 представлен ниже.

URI определяет путь к запрашиваемому документу.

Версия (англ. Version) - пара разделённых точкой цифр. Например: 1.0

Стартовая строка ответа сервера имеет следующий формат: HTTP/Версия КодСостояния Пояснение , где:

Версия - пара разделённых точкой цифр как в запросе.

Код состояния (англ. Status Code) - три цифры. По коду состояния определяется дальнейшее содержимое сообщения и поведение клиента.

Пояснение (англ. Reason Phrase) - текстовое короткое пояснение к коду ответа для пользователя. Никак не влияет на сообщение и является необязательным.

Например, стартовая строка ответа сервера на предыдущий запрос может выглядеть так:

Методы

Метод HTTP (англ. HTTP Method) - последовательность из любых символов, кроме управляющих и разделителей, указывающая на основную операцию над ресурсом. Обычно метод представляет собой короткое английское слово, записанное заглавными буквами. Обратите внимание, что название метода чувствительно к регистру.

Каждый сервер обязан поддерживать как минимум методы GET и HEAD. Если сервер не распознал указанный клиентом метод, то он должен вернуть статус 501 (Not Implemented). Если серверу метод известен, но он неприменим к конкретному ресурсу, то возвращается сообщение с кодом 405 (Method Not Allowed). В обоих случаях серверу следует включить в сообщение ответа заголовок Allow со списком поддерживаемых методов.

Кроме методов GET и HEAD, часто применяется метод POST.

OPTIONS Используется для определения возможностей веб-сервера или параметров соединения для конкретного ресурса. В ответ серверу следует включить заголовок Allow со списком поддерживаемых методов. Также в заголовке ответа может включаться информация о поддерживаемых расширениях.

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

Для того, чтобы узнать возможности всего сервера, клиент должен указать в URI звёздочку - «*». Запросы «OPTIONS * HTTP/1.1» могут также применяться для проверки работоспособности сервера (аналогично «пингованию») и тестирования на предмет поддержки сервером протокола HTTP версии 1.1.

Результат выполнения этого метода не кэшируется.

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

Клиент может передавать параметры выполнения запроса в URI целевого ресурса после символа «?»:

GET /path/resource?param1=value1¶m2=value2 HTTP/1.1

Аналогичен методу GET, за исключением того, что в ответе сервера отсутствует тело. Запрос HEAD обычно применяется для извлечения метаданных, проверки наличия ресурса (валидация URL) и чтобы узнать, не изменился ли он с момента последнего обращения.

Заголовки ответа могут кэшироваться. При несовпадении метаданных ресурса с соответствующей информацией в кэше копия ресурса помечается как устаревшая.

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

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

При результате выполнения 200 (Ok) в тело ответа следует включить сообщение об итоге выполнения запроса. Если был создан ресурс, то серверу следует вернуть ответ 201 (Created) с указанием URI нового ресурса в заголовке Location.

Сообщение ответа сервера на выполнение метода POST не кэшируется.

Применяется для загрузки содержимого запроса на указанный в запросе URI. Если по заданному URI не существовало ресурса, то сервер создаёт его и возвращает статус 201 (Created). Если же был изменён ресурс, то сервер возвращает 200 (Ok) или 204 (No Content). Сервер не должен игнорировать некорректные заголовки Content-*, передаваемые клиентом вместе с сообщением. Если какой-то из этих заголовков не может быть распознан или не допустим при текущих условиях, то необходимо вернуть код ошибки 501 (Not Implemented).

Фундаментальное различие методов POST и PUT заключается в понимании предназначений URI ресурсов. Метод POST предполагает, что по указанному URI будет производиться обработка передаваемого клиентом содержимого. Используя PUT, клиент предполагает, что загружаемое содержимое соответствует находящемуся по данному URI ресурсу.

Сообщения ответов сервера на метод PUT не кэшируются.

Аналогично PUT, но применяется только к фрагменту ресурса.

Удаляет указанный ресурс.

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

Устанавливает связь указанного ресурса с другими.

Убирает связь указанного ресурса с другими.

Преобразует соединение запроса в прозрачный TCP/IP туннель, обычно чтобы содействовать установлению защищенного SSL соединения через нешифрованный прокси.

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-глаголы в случае с капиталом . Итак, ниже показано сравнение между ними.

1. create - POST
2. читать - GET
3. update - PUT
4. 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

Приведенное ниже определение взято из примера из реального мира.

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

1. СООБЩЕНИЕ

   • Если Клиент отправляет данные без идентификатора с использованием метода POST, мы сохраняем их и назначаем новый идентификатор.
   • Если Клиент снова отправляет те же данные без идентификатора с помощью метода POST, мы сохраняем их и назначаем новый идентификатор.
   • Примечание : дублирование разрешено здесь

2. ПОЛОЖИЛ

   • Если Клиент отправляет данные с идентификатором, мы проверим, существует ли этот идентификатор. Если идентификатор существует, мы обновим данные, в противном случае мы создадим его и назначим новый идентификатор.
3. • Если Клиент отправляет данные с идентификатором, мы проверим, существует ли этот идентификатор. Если идентификатор существует, мы обновим данные, иначе мы сгенерируем исключение.

Примечание. В методе 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

Насколько я понимаю все это, то, если сравнить 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

Этот пост - ответ на вопрос, заданный в комментарии к одной из моих статей.

В статье я хочу рассказать, что же из себя представляют HTTP-методы GET/POST/PUT/DELETE и другие, для чего они были придуманы и как их использовать в соответствии с REST.

HTTP

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

Стартовые строки для запроса и ответа имеют различный формат - нам интересна только стартовая строка запроса, которая выглядит так:

METHOD URI HTTP/VERSION ,

Где METHOD - это как раз метод HTTP-запроса, URI - идентификатор ресурса, VERSION - версия протокола (на данный момент актуальна версия 1.1).

Заголовки - это набор пар имя-значение, разделенных двоеточием. В заголовках передается различная служебная информация: кодировка сообщения, название и версия браузера, адрес, с которого пришел клиент (Referrer) и так далее.

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

Пример HTTP-взаимодействия

Запрос:
GET /index.php HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; ru; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Accept: text/html Connection: close
Первая строка - это строка запроса, остальные - заголовки; тело сообщения отсутствует

Ответ:
HTTP/1.0 200 OK Server: nginx/0.6.31 Content-Language: ru Content-Type: text/html; charset=utf-8 Content-Length: 1234 Connection: close ... САМА HTML-СТРАНИЦА...

Ресурсы и методы

Тип HTTP-запроса (также называемый HTTP-метод) указывает серверу на то, какое действие мы хотим произвести с ресурсом. Изначально (в начале 90-х) предполагалось, что клиент может хотеть от ресурса только одно - получить его, однако сейчас по протоколу HTTP можно создавать посты, редактировать профиль, удалять сообщения и многое другое. И эти действия сложно объединить термином «получение».

Для разграничения действий с ресурсами на уровне HTTP-методов и были придуманы следующие варианты:

• GET - получение ресурса
• POST - создание ресурса
• PUT - обновление ресурса
• DELETE - удаление ресурса

В игру вступает REST

REST предлагает отказаться от использования одинаковых URI для разных ресурсов (то есть адреса двух разных статей вроде /index.php?article_id=10 и /index.php?article_id=20 - это не REST-way) и использовать разные HTTP-методы для разных действий. То есть веб-приложение, написанное с использованием REST подхода будет удалять ресурс при обращении к нему с HTTP-методом DELETE (разумеется, это не значит, что надо давать возможность удалить всё и вся, но любой запрос на удаление в приложении должен использовать HTTP-метод DELETE).

REST дает программистам возможность писать стандартизованные и чуть более красивые веб-приложения, чем раньше. Используя REST, URI для добавления нового юзера будет не /user.php?action=create (метод GET/POST), а просто /user.php (метод строго POST).

В итоге, совместив имеющуюся спецификацию HTTP и REST-подход наконец-то обретают смысл различные HTTP-методы. GET - возвращает ресурс, POST - создает новый, PUT - обновляет существующий, DELETE - удаляет.

Проблемы?

PUT/DELETE запросы можно отправлять посредством XMLHttpRequest, посредством обращения к серверу «вручную» (скажем, через curl или даже через telnet), но нельзя сделать HTML-форму, отправляющую полноценный PUT/DELETE-запрос.

Дело в том, спецификация HTML не позволяет создавать формы, отправляющие данные иначе, чем через GET или POST. Поэтому для нормальной работы с другими методами приходится имитировать их искусственно. Например, в Rack (механизм, на базе которого Ruby взаимодействует с веб-сервером; с применением Rack сделаны Rails, Merb и другие Ruby-фреймворки) в форму можно добавить hidden-поле с именем "_method", а в качестве значения указать название метода (например, «PUT») - в этом случае будет отправлен POST-запрос, но Rack сможет сделать вид, что получил PUT, а не POST.