Activity 29: HTTP Methods
HTTP request methods
HTTP defines a set of request methods to indicate the purpose of the request and what is expected if the request is successful. Although they can also be nouns, these request methods are sometimes referred to as HTTP verbs. Each request method has its own semantics, but some characteristics are shared across multiple methods, specifically request methods can be safe, idempotent, or cacheable.
GET
The GET method requests a representation of the specified resource. Requests using GET should only retrieve data and should not contain a request content.
Syntax
GET <request-target>["?"<query>] HTTP/1.1
<request target>
Identifies the target resource of the request when combined with the information provided in the Host header. This is an absolute path (e.g., /path/to/file.html) in requests to an origin server, and an absolute URL in requests to proxies (e.g., http://www.example.com/path/to/file.html).
<query>
An optional query component preceded by a question-mark ?. Often used to carry identifying information in the form of key=value pairs.
Examples:
Successfully retrieving resource
GET /contact HTTP/1.1
Host: example.com
User-Agent: curl/8.6.0
Accept: */*
The server sends back the resource with a 200 OK status code, indicating success:
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Date: Fri, 21 Jun 2024 14:18:33 GMT
Last-Modified: Thu, 17 Oct 2019 07:18:26 GMT
Content-Length: 1234
<!doctype html>
<!-- HTML content follows -->
POST
The POST method submits an entity to the specified resource, often causing a change in state or side effects on the server.
The post HTTP method sends data to the server. The type of the body of the request is indicated by the Content-Type header.
The difference between put and post is that PUT is idempotent: calling it once is no different from calling it several times successively (there are no side effects). Successive identical post requests may have additional effects, such as creating the same order several times.
When the post request is sent following a fetch() call, or for any other reason than an HTML form, the body can be any type. As described in the HTTP 1.1 specification, post is designed to allow a uniform method to cover the following functions:
Annotation of existing resources
Posting a message to a bulletin board, newsgroup, mailing list, or similar group of articles
Adding a new user through a signup form
Providing a block of data, such as the result of submitting a form, to a data-handling process
Extending a database through an append operation
Syntax
POST <request-target>["?"<query>] HTTP/1.1
<request-target>
Identifies the target resource of the request when combined with the information provided in the Host header. This is an absolute path (e.g., /path/to/file.html) in requests to an origin server, and an absolute URL in requests to proxies (e.g., http://www.example.com/path/to/file.html)
<query>
An optional query component preceded by a question-mark ?. Often used to carry identifying information in the form of key=value pairs.
URL-encoded form submission
A form using application/x-www-form-urlencoded content encoding (the default) sends a request where the body contains the form data in key=value pairs, with each pair separated by an & symbol, as shown below:
HTTP
POST /test HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 27
field1=value1&field2=value2
Multipart form submission
The multipart/form-data encoding is used when a form includes files or a lot of data. This request body delineates each part of the form using a boundary string. An example of a request in this format:
POST /test HTTP/1.1
Host: example.com
Content-Type: multipart/form-data;boundary="delimiter12345"
--delimiter12345
Content-Disposition: form-data; name="field1"
value1
--delimiter12345
Content-Disposition: form-data; name="field2"; filename="example.txt"
value2
--delimiter12345--
The Content-Disposition header indicates how the form data should be processed, specifying the field name and filename, if appropriate.
PUT
The PUT method replace all the representations of the target resource with the request content.
Syntax
HTTP
PUT <request-target>["?"<query>] HTTP/1.1
<request-target>
Identifies the target resource of the request when combined with the information provided in the Host header. This is an absolute path (e.g., /path/to/file.html) in requests to an origin server, and an absolute URL in requests to proxies (e.g., http://www.example.com/path/to/file.html).
<query>
An optional query component preceded by a question-mark ?. Often used to carry identifying information in the form of key=value pairs.
Examples:
Successfully creating resource
The following PUT request asks to create a resource at example.com/new.html with the content <p>New File</p>:
PUT /new.html HTTP/1.1
Host: example.com
Content-type: text/html
Content-length: 16
<p>New File</p>
If the target resource does not have a current representation and the PUT request successfully creates one, then the origin server must send a 201 Created response:
HTTP
HTTP/1.1 201 Created
Content-Location: /new.html
If the target resource does have a current representation and that representation is successfully modified with the state in the request, the origin server must send either a 200 OK or a 204 No Content to indicate successful completion of the request:
HTTP
HTTP/1.1 204 No Content
Content-Location: /existing.html
DELETE
The DELETE method deletes the specified resource.
The DELETE method has no defined semantics for the message body, so this should be empty.
Syntax
HTTP
DELETE <request-target>["?"<query>] HTTP/1.1
<request-target>
Identifies the target resource of the request when combined with the information provided in the Host header. This is an absolute path (e.g., /path/to/file.html) in requests to an origin server, and an absolute URL in requests to proxies (e.g., http://www.example.com/path/to/file.html).
<query>
An optional query component preceded by a question-mark ?. Often used to carry identifying information in the form of key=value pairs.
Examples:
Successfully deleting resource
The following request asks the server to delete the resource file.html:
http
DELETE /file.html HTTP/1.1
Host: example.com
If the request is successful, there are several possible successful response status codes. A 204 No Content response means the request was successful and no additional information needs to be sent back to the client:
HTTP
HTTP/1.1 204 No Content
Date: Wed, 04 Sep 2024 10:16:04 GMT
A 200 OK response means the request was successful and the response body includes a representation describing the outcome:
http
HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Date: Fri, 21 Jun 2024 14:18:33 GMT
Content-Length: 1234
<html>
<body>
<h1>File "file.html" deleted.</h1>
</body>
</html>
A 202 Accepted response means the request has been accepted and will probably succeed, but the resource has not yet been deleted by the server.
http
HTTP/1.1 202 Accepted
Date: Wed, 26 Jun 2024 12:00:00 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 1234
<html>
<body>
<h1>Deletion of "file.html" accepted.</h1>
<p>See <a href="http://example.com/tasks/123/status">the status monitor</a> for details.</p>
</body>
</html>
PATCH
The PATCH method applies partial modifications to a resource.
Patch is somewhat analogous to the "update" concept found in CRUD (in general, HTTP is different than CRUD, and the two should not be confused).
In comparison with PUT, a PATCH serves as a set of instructions for modifying a resource, whereas PUT represents a complete replacement of the resource. A PUT request is always idempotent (repeating the same request multiple times results in the resource remaining in the same state), whereas a PATCH request may not always be idempotent. For instance, if a resource includes an auto-incrementing counter, a PUT request will overwrite the counter (since it replaces the entire resource), but a PATCH request may not.
Like Post, a PATCH request can potentially have side effects on other resources.
Syntax
http
<request-target>
Identifies the target resource of the request when combined with the information provided in the Host header. This is an absolute path (e.g., /path/to/file.html) in requests to an origin server, and an absolute URL in requests to proxies (e.g.,
http://www.example.com/path/to/file.html).
<query>
An optional query component preceded by a question-mark ?. Often used to carry identifying information in the form of key=value pairs.
Examples:
Successfully modifying resource
Assume there is a resource on the server representing a user with a numeric ID of 123 in the following format:
json
{
"firstName": "Example",
"LastName": "User",
"userId": 123,
"signupDate": "2024-09-09T21:48:58Z",
"status": "active",
"registeredDevice": {
"id": 1,
"name": "personal",
"manufacturer": {
"name": "Hardware corp"
}
}
}
Instead of sending a JSON object to fully overwrite a resource, a PATCH modifies only specific parts of the resource. This request updates the status field:
http
PATCH /users/123 HTTP/1.1
Host: example.com
Content-Type: application/json
Content-Length: 27
Authorization: Bearer ABC123
{
"status": "suspended"
}
The interpretation and authentication of the PATCH request depend on the implementation. Success can be indicated by any of the successful response status codes. In this example, a 204 No Content is used as there's no need to transmit a body with additional context about the operation. An ETag is provided so the caller can perform a conditional request in future:
http
HTTP/1.1 204 No Content
Content-Location: /users/123
ETag: "e0023aa4f"