Методы get и post. использование и отличия

POST и GET запросы простыми словами

Эта переменная будет отправлена методом POST.

Если в форме написать так:

То данные будут отправляться методом GET.

Если, в случае с GET-запросом, объем данных, которые мы могли передать ограничивался длиной адресной строки браузера, то в случае с запросом POST, такого ограничения нет, и мы можем передавать значительные объемы информации.

Еще одно отличие метода POST от GET, метод POST скрывает все передаваемые им переменные и их значения, в своём теле (Entity-Body). В случае с методом GET они хранились в строке запроса (Request-URI).

Вот пример запроса, выполненного методом POST:

POST / HTTP/1.0\r\n Host: www.site.ru\r\n Referer: http://www.site.ru/index.html\r\n Cookie: income=1\r\n Content-Type: application/x-www-form-urlencoded\r\n Content-Length: 35\r\n \r\n login=Dima&password=12345

Таким образом, передавая данные методом POST, их будет намного труднее перехватить злоумышленнику, т.к. они скрыты от непосредственного просмотра, поэтому метод передачи данных методом POST считается более безопасным способом.

Кроме того, методом POST можно передавать не только текст, но и мультимедиа данные (картинки, аудио, видео). Существует специальный параметр Content-Type, который определяет тот вид информации, который необходимо передать.

Ну и, наконец, чтобы на сервере получить данные, которые были переданы этим методом, используется переменная POST.

Вот пример обработки на языке PHP:

<?php echo $_POST; ?>

Кстати, хотите узнать есть ли смысл в каком-то элементе на вашем сайте с помощью «целей» Яндекс Метрики и Google Analytics?

Уберите то, что НЕ работает, добавьте то, что работает и удвойте вашу выручку.

Курс по настройке целей Яндекс Метрики..

1.2. Пишем наш первый HTTP запрос

Если Вы думаете, что все слишком сложно, то Вы ошибаетесь. Человек так устроен, что просто не способен создавать что-то сложное, иначе он сам в этом запутается 🙂 Итак, есть браузер и есть Web-сервер. Инициатором обмена данными всегда выступает браузер. Web-сервер никому, никогда просто так ничего не пошлет, чтобы он что-нибудь отправил браузеру — надо, чтобы браузер об этом попросил. Простейший HTTP запрос моет выглядеть, например, так:

GET http://www.php.net/ HTTP/1.0\r\n\r\n

GET (В переводе с английского означает «получить») — тип запроса, тип запроса может быть разным, например POST, HEAD, PUT, DELETE (часть из них мы рассмотрим ниже).
http://www.php.net/ — URI (адрес) от которого мы хотим получить хоть какую-нибудь информацию (естественно мы надеемся подучить HTML страницу).
HTTP/1.0 — тип и версия протокола, который мы будем использовать в процессе общения с сервером.
\r\n — конец строки, который необходимо повторить два раза, зачем, станет понятно немного позднее.

What Are the Various Types of HTTP Request Methods?

GET

GET is used to retrieve and request data from a specified resource in a server. GET is one of the most popular HTTP request techniques. In simple words, the GET method is used to retrieve whatever information is identified by the Request-URL.

HEAD

The HEAD technique requests a reaction that is similar to that of GET request, but doesn’t have a message-body in the response. The HEAD request method is useful in recovering meta-data that is written according to the headers, without transferring the entire content. The technique is commonly used when testing hypertext links for accessibility, validity, and recent modification.

POST

Another popular HTTP request method is POST. In web communication, POST requests are utilized to send data to a server to create or update a resource. The information submitted to the server with POST request method is archived in the request body of the HTTP request. The HTTP POST method is often used to send user-generated data to a server. One example is when a user uploads a profile photo.

PUT

PUT is similar to POST as it is used to send data to the server to create or update a resource. The difference between the two is that PUT requests are idempotent. This means that if you call the same PUT requests multiple times, the results will always be the same.

DELETE

Just as it sounds, the DELETE request method is used to delete resources indicated by a specific URL. Making a DELETE request will remove the targeted resource.

PATCH

A PATCH request is similar to POST and PUT. However, its primary purpose is to apply partial modifications to the resource. And just like a POST request, the PATCH request is also non-idempotent. Additionally, unlike POST and PUT which require a full user entity, with PATCH requests, you may only send the updated username.

TRACE

TRACE requests are used to invoke a remote, application loop-back test along the path to the target resource. The TRACE method allows clients to view whatever message is being received at the other end of the request chain so that they can use the information for testing or diagnostic functions.

CONNECT

The CONNECT request method is used by the client to create a network connection to a web server over a particular HTTP. A good example is SSL tunneling. In a nutshell, CONNECT request establishes a tunnel to the server identified by a specific URL.

Как работает HTTP, и зачем нам это знать

Программировать на PHP можно и без знания протокола HTTP, но есть ряд ситуаций, когда для решения задач нужно знать, как именно работает веб-сервер. Ведь PHP — это, в первую очередь, серверный язык программирования.

Протокол HTTP очень прост и состоит, по сути, из двух частей:

Заголовков запроса/ответа;
Тела запроса/ответа.

Сначала идёт список заголовков, затем пустая строка, а затем (если есть) тело запроса/ответа.

И клиент, и сервер могут посылать друг другу заголовки и тело ответа, но в случае с клиентом доступные заголовки будут одни, а с сервером — другие. Рассмотрим пошагово, как будет выглядеть работа по протоколу HTTP в случае, когда пользователь хочет загрузить главную страницу социальной сети «Вконтакте».

1. Браузер пользователя устанавливает соединение с сервером vk.com и отправляет следующий запрос:

GET / HTTP/1.1
Host: vk.com

2. Сервер принимает запрос и отправляет ответ:

3. Браузер принимает ответ и показывает готовую страницу

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

Метод, которым будет запрошен контент;
Адрес страницы;
Версию протокола.

— это метод (глагол), который мы применяем для доступа к указанной странице. является самым часто используемым методом, потому что он говорит серверу о том, что клиент всего лишь хочет прочитать указанный документ. Но помимо есть и другие методы, один из них мы рассмотрим уже в следующем разделе.

После метода идет указание на адрес страницы — URI (универсальный идентификатор ресурса). В нашем случае мы запрашиваем главную страницу сайта, поэтому используется просто слэш — .
Последним в этой строке идет версия протокола и почти всегда это будет

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

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

Больше всего здесь интересен именно код состояния, он же код ответа сервера.
В этом примере код ответа — 200, что означает: сервер работает, документ найден и будет передан клиенту. Но не всегда всё идет гладко.
Например, запрошенный документ может отсутствовать или сервер будет перегружен, в таком случае клиент не получит контент, а код ответа будет отличным от 200.

404 — если сервер доступен, но запрошённый документ не найден;
503 — если сервер не может обрабатывать запросы по техническим причинам.

Спецификация HTTP 1.1 определяет 40 различных кодов HTTP.

После стартовой строки следуют заголовки, а затем тело ответа.

Необходимые disclaimer-ы

во-первых, далее речь пройдет про C++. Если вам не нравится C++, если вы считаете, что C++ не место в современном мире вообще и в подобных задачах в частности, то эта статья не для вас. И у нас нет цели убедить кого-то в том, что C++ хорош и должен использоваться в таких задачах. Мы лишь рассказываем о том, как можно решить подобную задачу на C++ если вам вдруг пришлось это делать именно на C++. Так же мы не будем спорить о том, почему может такое потребоваться и почему в реальной жизни нельзя просто взять и переписать существующий C++ код на чем-то еще;
во-вторых, в C++ нет общепринятого code convention, поэтому какие-либо претензии со стороны приверженцев camelCase, PascalCase, Camel_With_Underscores_Case или даже UPPER_CASE восприниматься не будут. Мы постарались привести код в более-менее похожий на K&R стиль, дабы он выглядел привычно для наибольшего количества читателей. Ибо наш «фирменный» стиль оформления С++кода точно приемлют не все. Однако, если внешний вид кода нарушает ваши эстетические чувства и вы готовы высказать в комментариях свое веское «фи» по этому поводу, то задумайтесь, пожалуйста, вот о чем: всегда есть кто-то, кому не нравится используемый вами стиль. Всегда. Вне зависимости от того, какой именно стиль вы используете;
в-третьих, показанный нами код ни в коем случае не претендует на звание образца качества и надежности. Это не предназначенный для продакшена код. То, что вы увидите — это quick-and-dirty прототип, который был слеплен на коленке буквально за день и еще один день был потрачен на то, чтобы хоть чуть-чуть причесать получившийся код и снабдить его поясняющими комментариями. Так что претензии вида «да кто так пишет» или «за такой говнокод нужно бить по рукам» не принимаются, т.к. мы сами себе их высказываем 😉

В чем суть разработанной имитации?

bridge_server_1_pipe. Более сложный вариант bridge_server_1. Так же две рабочие нити, но используется дополнительный pipe для передачи нотификаций от нити RESTinio к нити libcurl-а. Изначально эту реализацию описывать мы не планировали, но если у кого-то будет интерес, то можно будет рассмотреть bridge_server_1_pipe в деталях в дополнительной статье;

Специфика HTTP

Интернет протокол HTTP отличается от других протоколов тем, что создает отдельную TCP-сессию на любой запрос. В следующих версиях протокола было разрешено выполнять несколько запросов во время одной TCP-сессии. Но при этом браузеры, как правило, делают запрос только на страницу и находящиеся в ней объекты (изображения, таблицы стилей и так далее), а затем сразу прерывают TCP-сессию.

TCP/IP

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

HTTP Request Methods

The internet boasts a vast array of resources hosted on different servers. For you to access these resources, your browser needs to be able to send a request to the servers and display the resources for you. HTTP (Hypertext Transfer Protocol), is the underlying format that is used to structure request and responses for effective communication between a client and a server. The message that is sent by a client to a server is what is known as an HTTP request. When these requests are being sent, clients can use various methods.

Therefore, HTTP request methods are the assets that indicate the specific desired action to be performed on a given resource. Each method implements a distinct semantic, but there are some standard features shared by the various HTTP request methods.

Request Method

The request method indicates the method to be performed on the resource identified by the given Request-URI. The method is case-sensitive and should always be mentioned in uppercase. The following table lists all the supported methods in HTTP/1.1.

S.N.	Method and Description
1	GET The GET method is used to retrieve information from the given server using a given URI. Requests using GET should only retrieve data and should have no other effect on the data.
2	HEAD Same as GET, but it transfers the status line and the header section only.
3	POST A POST request is used to send data to the server, for example, customer information, file upload, etc. using HTML forms.
4	PUT Replaces all the current representations of the target resource with the uploaded content.
5	DELETE Removes all the current representations of the target resource given by URI.
6	CONNECT Establishes a tunnel to the server identified by a given URI.
7	OPTIONS Describe the communication options for the target resource.
8	TRACE Performs a message loop back test along with the path to the target resource.

Резюме¶

Протокол HTTP это:

однонаправленный (запрос/ответ)
текстовый протокол
не хранит состояния
работает на сетевом уровне только через TCP
может передавать любые данные
используется не только в браузерах
обслуживает львиную долю Интернет трафика

Достоинства

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

Недостатки

Избыточность передаваемой информации, и как следствие, большой размер
сообщений по сравнению с передачей двоичных данных. Это нивелируется
внедрением кэширования на стороне клиента, компрессии передаваемых данных
от сервера. Также улучшает ситуацию использование прокси-серверов,
позволяющих передавать информацию клиенту с наиболее близкого сервера,
diff-кодирование, благодаря которому клиенту передается не весь объем
данных, а только измененная их часть.
Отсутствие навигации. У протокола отсутствую средства навигации среди
ресурсов сервера. Клиент не может, как в FTP запросить список доступных
файлов. Протокол предполагает, что пользователю уже известен URI
интересующего его ресурса.

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

Карта сайта может использоваться как пользователем, так и
роботами-пауками поисковых систем, уменьшая для них глубину
просмотра—минимально необходимое количество переходов с главной страницы.
Аналогичную функцию выполняют и файлы sitemap, но только для
приложений. Данная проблема полностью решена в протоколе более высокго
уровня WebDAV с помощью добавленного метода PROPFIND, который
позволяет получить не только дерево каталогов, но и список параметров
каждого ресурса.
Отсутствие поддержки распределённости. Изначально протокол HTTP
разрабатывался для решения типичных бытовых задач, где само по себе время
обработки запроса должно занимать незначительное время или вовсе не
приниматься в расчёт. Однако со временем стало очевидно, что при
промышленном использовании с применением распределённых вычислений при
высоких нагрузках на сервер протокол HTTP оказывается непригоден. В
связи с этим с 1998 году был предложен альтернативный протокол HTTP-NG (англ. HTTP Next
Generation), но этот протокол до сих пор находится на стадии разработки.

DELETE Method

The DELETE method is used to request the server to delete a file at a location specified by the given URL. The following example requests the server to delete the given file hello.htm at the root of the server:

DELETE /hello.htm HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Accept-Language: en-us
Connection: Keep-Alive

The server will delete the mentioned file hello.htm and will send the following response back to the client:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Content-type: text/html
Content-length: 30
Connection: Closed

<html>
<body>
<h1>URL deleted.</h1>
</body>
</html>

URL¶

См.также

https://ru.wikipedia.org/wiki/URL

URL (Uniform Resource Locator) – унифицированный указатель на ресурс.

Основным объектом манипуляции в HTTP является ресурс, на который указывает
URL в запросе клиента. Список всех доступных ресурсов сайта образуют дерево,
в котором каждая ветка будет являться адресом URL.

Дерево доступных ресурсов сайта

Ресурсы представляют из себя либо реальные файлы на сервере, например: HTML,
js, png, …, либо логические сущности, которые генерируют содержимое на лету
(в момент поступления запроса), например: список новостей, погода, фотогалерея,
каталог товаров и прочее. Соответственно такие ресурсы называют статическими
(неизменными) или динамическими.

Еще существуют абстрактные ресурсы, которые присутствуют в пути но этот
адрес самостоятельно не существует, например:

http://example.com/ – главная страница сайта
http://example.com/blog/ – список статей
http://example.com/blog/article/1 – статья 1 в блоге
http://example.com/blog/article/ – абстрактный ресурс, который присутствует
в пути, но реально его не существует. По данной ссылке сервер вернет ошибку
404 Not Found. Такие ресурсы нужны для большей читаемости URL и
семантического разделения сущностей.

URI

См.также

https://ru.wikipedia.org/wiki/URI
URI,URL,URN

URL является подмножеством более широкого термина URI (Uniform Resource
Identifier), который обобщает вид различных идентификаторов.

Примеры URI:

ldap:///c=GB?objectClass?one

mailto:John.Doe@example.com

news:comp.infosystems.www.servers.unix

tel:+1-816-555-1212

telnet://192.0.2.16:80/

ftp://ftp.is.co.za/rfc/rfc1808.txt

http://www.ietf.org/rfc/rfc2396.txt

urn:oasis:names:specification:docbook:dtd:xml:4.1.2

URN

См.также

https://ru.wikipedia.org/wiki/URN

URN (Uniform Resource Name) — идентифицирует путь до ресурса.

Пример:

URI =
URL = http://lectureskpd.readthedocs.io
URN = /kpd/3.http.html

Идентификатор ресурса можно представить в виде формулы:

URI = URL + URN

Примечание

В обществе URI часто назвают как URL.

Структура URL

См.также

http://www.ietf.org/rfc/rfc3986.txt

Структура URL представлена на схеме ниже:

 foo://example.com:8042/over/there?name=ferret#nose
 \_/   \______________/\_________/ \_________/ \__/
  |           |            |            |        |
схема   имя(IP) и порт    путь        запрос   элемент
  |   _____________________|__
 / \ /                        \
 urn:example:animal:ferret:nose

<схема>://<логин>:<пароль>@<хост>:<порт>/<URN ‐ путь>?<параметры>#<якорь>

ws
ftp
http
https
file
mailto
xmpp

<схема>://<логин>:<пароль>@<хост>:<порт>/<URN ‐ путь>?<параметры>#<якорь>

user:123
user

Адрес ресурса

<схема>://<логин>:<пароль>@ <хост>:<порт>/<URN ‐ путь>?<параметры>#<якорь>

localhost:8080
yandex.ru
213.180.204.11
127.0.0.1:6543
yandex.ru:80
192.168.0.13:22

Пара <хост>:<порт> называется INET SOCKET или просто сокет, определяет
входную точку приложения и идентифицирует адрес по которому с ним можно
связаться.

HTTP по умолчанию использует порт 80, это знают веб-сервера, поэтому его можно не указывать.

<схема>://<логин>:<пароль>@<хост>:<порт>/<URN ‐ путь>?<параметры>#<якорь>

somedir/somefile.html

<схема>://<логин>:<пароль>@<хост>:<порт>/<URN ‐ путь>? <параметры>#<якорь>

text=foobar&from=fx3&lr=213

Якорь

<схема>://<логин>:<пароль>@<хост>:<порт>/<URN ‐ путь>?<параметры># <якорь>

someanchor

Якорь указывает на расположение в самом документе.
Пример якоря

HTTP PATCH

HTTP PATCH requests are to make partial update on a resource. If you see PUT requests also modify a resource entity, so to make more clear – PATCH method is the correct choice for partially updating an existing resource, and PUT should only be used if you’re replacing a resource in its entirety.

Please note that there are some challenges if you decide to use PATCH APIs in your application:

Support for PATCH in browsers, servers, and web application frameworks is not universal. IE8, PHP, Tomcat, Django, and lots of other software has missing or broken support for it.
Request payload of a PATCH request is not straightforward as it is for PUT request. e.g.
produces below response:

[ { “op”: “replace”, “path”: “/email”, “value”: “” } ]

There may be following possible operations are per the HTTP specification.

The PATCH method is not a replacement for the POST or PUT methods. It applies a delta (diff) rather than replacing the entire resource.

Выбираем российского провайдера для интеграции с WhatsApp

Собственно, почему выбираем именно провайдера и почему российского? WhatsApp, создавая свое API, преследовал две цели — делать деньги и минимизировать спам. И чтобы убить сразу двух зайцев, было принято решение предлагать API исключительно через партнеров. Ну а вопрос по поводу российского партнера скорее уже риторический. И не только из-за курса рубля, но и из-за таланта работать с российскими телефонными номерами, коим одарены далеко не все провайдеры. Между тем статья не претендует на всесторонний анализ всех возможностей всех провайдеров. Мы копнем лишь верхушку айсберга этого немаленького рынка.

1 стартмани

HTTP-запросы

Каждый клиент посылает запрос, и сервер на него отвечает. Все запросы и ответы состоят из трех частей, а именно: строки запроса или ответа, секции заголовков и тела сущности (любого содержания, отправляемого вместе с сообщением, например, страницы HTML для отображения в браузере или данных формы, пересылаемых на сервер).

Клиент связывается с сервером в назначенном номере порта (по умолчанию равном 80) и запрашивает у сервера документ, задавая HTTP-команду, называемую методом, за которой следует адрес документа и номер версии HTTP. Клиент также отправляет серверу необязательную информацию в заголовках, чтобы сообщить серверу о своей конфигурации и приемлемых для него форматах документов. Информация заголовка дается в одной строке вместе с именем и значением заголовка. После заголовков клиент посылает пустую строку. Затем клиент отправляет дополнительные данные. Это могут быть данные формы, отправляемые на сервер методом POST, или файл, копируемый на сервер методом PUT.

Запросы клиентов подразделяются на три секции. Первая строка сообщения всегда должна содержать HTTP-команду, называемую методом, за которой следует URI, идентифицирующий файл или ресурс, запрашиваемый клиентом, и номер версии HTTP:

GET /default.aspx HTTP/1.1

Теперь исследуем каждую из этих секций. Метод — это HTTP-команда, начинающая первую строку запроса клиента. Метод информирует сервер о цели запроса клиента. Для HTTP определены семь методов: GET, HEAD, POST, OPTIONS, PUT, DELETE и TRACE, но HTTP-серверы могут также реализовать методы расширения, не определенные протоколом HTTP. Заметим, что названия методов зависят от регистра клавиатуры, поэтому, например, слово get не будет распознано как допустимый метод.

Метод GET используется для запроса информации, расположение которой на сервере определяется заданным URI. Этот метод широко применяется браузерами, чтобы извлекать документы для просмотра. Результат запроса GET генерируется разными способами. Это может быть файл, доступный с сервера, вывод программы, вывод, полученный на устройстве, и т. д.

Когда клиент в своем запросе использует метод GET, сервер отправляет ответ, содержащий строку состояния, заголовки и метаданные. Если сервер не может обработать запрос из-за ошибки или отсутствия авторизации, он отправляет объяснение в текстовом виде, помещая его в ответе в секцию данных.

Секция тела о сути запроса GET всегда остается пустой. Запрошенный клиентом ресурс (файл или программа) идентифицируется по его полному пути на сервере. Любая дополнительная информация, например, значения из формы, которую клиенту нужно отправить серверу, присоединяется вслед за URI как строка запроса:

GET /default.aspx?name=Alex HTTP/1.1

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

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

В методе OPTIONS запрашивается информация о поддержке HTTP на Web-cepвeре. Метод OPTIONS может применяться с URL, чтобы извлечь информацию о конкретном документе или, с групповым символом *, чтобы получить информацию о возможностях сервера в целом. Информация возвращается в заголовках ответа.

HTTP DELETE

As the name applies, DELETE APIs are used to delete resources (identified by the Request-URI).

A successful response of DELETE requests SHOULD be HTTP response if the response includes an entity describing the status, if the action has been queued, or if the action has been performed but the response does not include an entity.

DELETE operations are idempotent. If you DELETE a resource, it’s removed from the collection of resources. Repeatedly calling DELETE API on that resource will not change the outcome – however, calling DELETE on a resource a second time will return a 404 (NOT FOUND) since it was already removed. Some may argue that it makes the DELETE method non-idempotent. It’s a matter of discussion and personal opinion.

If the request passes through a cache and the Request-URI identifies one or more currently cached entities, those entries SHOULD be treated as stale. Responses to this method are not cacheable.

Example request URIs

HTTP DELETE http://www.appdomain.com/users/123
HTTP DELETE http://www.appdomain.com/users/123/accounts/456

POST Method

The POST method is used when you want to send some data to the server, for example, file update, form data, etc. The following example makes use of POST method to send a form data to the server, which will be processed by a process.cgi and finally a response will be returned:

POST /cgi-bin/process.cgi HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: 88
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

<?xml version="1.0" encoding="utf-8"?>
<string xmlns="http://clearforest.com/">string</string>

The server side script process.cgi processes the passed data and sends the following response:

HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache/2.2.14 (Win32)
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Vary: Authorization,Accept
Accept-Ranges: bytes
Content-Length: 88
Content-Type: text/html
Connection: Closed

<html>
<body>
<h1>Request Processed Successfully</h1>
</body>
</html>