HTTP Methods Primer
What happens when you type an address into the search bar and hit enter:
- The browser extracts the domain name from the search bar.
- The users Domain Name System (DNS) cache is queried. If no previous entries are found a DNS request is sent via your configured DNS server.
- After getting the IP address via DNS, the host will initiate a TCP connection with that address.
- If the connection is successful, a response will be sent from the server and its data will be rendered using HTTP.
For a more detailed explanation of DNS resolution in step 2, check out my post on the subject.
Hyper-Text Transfer Protocol (HTTP) is an application layer protocol for communications between a client and web server. It operates on a request-response model with the client initiating any connection to the server.
Each request starts with a HTTP method which defines the request semantics, indicating the purpose of the clients request and what the client expects in a successful response. More succinctly, the method tells the server what sort of data it is sending or wants to receive. The server can then respond appropriately to the request.
The nine methods available are listed below.
The most common request, it broadly asks the remote host to send the requested data back to the client. In general,
GET requests will retrieve the data from a Uniform Request Identifier (URI).
Responses to a
GET request are cacheable, meaning a cache can elect to use the it on subsequent
Very similar to the
GET request except that it only retrieves the header information. All body content is omitted.
Responses to a
HEAD request are cacheable, meaning a cache can elect to use the it on subsequent
POST request will typically be sent via a HTML form and will effect some change on the server. According the specification it is indicated by the
POST actions are things like adding new users, or payment processing. The
POST sends that information to the server for it to be processed and declares the scheme it will use to send the data. The server needs this information so it knows how to handle the request.
# Request POST /payments HTTP/1.1 Host: bank.com Content-Type: application/x-www-form-urlencoded Content-Length: 34 accountNumber=123&amount=9999&toAccount=789
POST requests should get a
201 Created response and a
Location header pointing to the data’s new URI.
# Response HTTP/1.1 201 Created Location: /payments/<ID>/<transactionID>
Similar to a
POST request, a
PUT references an already existing entity, and requests a update to it. The server must verify the validity of the data to be updated, and is not obligated to action the request.
PUT is idempotent whereas
POST requests are not. Each
POST will have an updating effect on the data. For instance, repeatedly sending a
POST on endpoints like payment processing could see that payment processed as many times as the request was sent.
This is one of the differences between the two at the HTTP level. But, the most important difference is how the each request interacts with the URI it is requesting.
PUT request must know the exact URI it intends to influence.
# Updates an existing record # OR adds a record to that exact URI PUT /api/v1/books/3452 HTTP/1.1 Host: https://library-store.com/
Should return a
200 OK or in some cases a
REST API’s usually adhere to the correct use of
POST requests. A URI such as above is a good indication of a REST conforming web application.
PUT which will replace an existing entity,
PATCH only modifies a portion of it. This makes it an non-idempotent method. Similar to
POST, it will make alterations or add data for each request. However, a
PATCH can be made idempotent - it depends on context and the data being modified.
This method is relatively new in comparison to its siblings, having been introduced as early as RFC 2616 but only being ratified in RFC 5789 circa 2010.
# Request PATCH /file.txt HTTP/1.1 Host: www.example.com Content-Type: application/example If-Match: "e0023aa4e" Content-Length: 100
A successful response generally yields a
204 No Content as no message body is present. A
200 OK requires a message body. Other codes can be configured by the server if required.
# Response HTTP/1.1 204 No Content Content-Location: /file.txt ETag: "e0023aa4f"
Note how the
ETag data match. This will be covered in a later post.
Is a request to the server that calls a function capable of deleting a specified entity. The server is responsible for checking and carrying out the function.
# Request DELETE /user/2341 HTTP/1.1
Should return a
204 No Content or
An uncommon request that is often seen during diagnostics such as Traceroute. Can see what the server was delivered.
Often this method is disabled as its an attack vector for Cross Site Tracing.
For use with a proxy to initiate the connection.
A utility call that asks the server which HTTP methods are supported.
allow header shows which options are authorized. Some applications prohibit the
OPTIONS method and will return a
4XX status code.
HTTP/2 200 allow: OPTIONS, GET, HEAD, POST cache-control: max-age=604800 content-type: text/html; charset=UTF-8 date: Sun, 14 Jul 2019 05:17:14 GMT expires: Sun, 21 Jul 2019 05:17:14 GMT server: EOS (vny006/044F) content-length: 0
Digging into the HTTP specifications and RFC’s has not been wasted effort. They underpin the Internet and all associated technologies that power it. Learn some for great good.
Keep up to date with my stuff
Subscribe to get new posts and retrospectives