The core protocol of the web
A Uniform Resource Locator is a reference to a resource on a network.
URLs are broken into their component pieces using the pattern described above.
e.g. https://www.example.com/some-document.html?key=value#some-element
Browsers make calls to DNS to lookup the domain name and convert it to an IP address which it uses to communicate to the server.
HyperText Transfer Protocol is the core mechanism for communicating between web clients (browsers) and web servers.
MDN has a great set of pages describing HTTP.
HTTP messages have a common structure.
Start line, Headers, empty line and body.
HTML only allows two request methods, GET and POST. They imply a different intent.
GET requests are safe and idempotent.
They imply a read-only request for a representation of a given resource. They can be issued and reissued many times without any problem.
- GET /items (give me the items)
- GET /items/123 (give me item number 123)
Data are passed in the URL as search parameters.
POST requests are neither safe nor are they guaranteed to be idempotent
They imply a request to change server state. Issuing the same POST request multiple times may change the state each time. e.g. by adding duplicate records into a collection.
Fundamentally, they submit data (in the request body) for the resource to process.
HTTP semantics is about intent, GET requests are for read-only operations, POST requests modify state.
Code
HTTP Response Codes should reflect the status of the processed request.
No problem, your request was processed successfully.
The result can be seen at another location. The browser will GET the provided URL.
This doesn’t make sense. Your request was not processed.
Poorly named as this really means unauthenticated, i.e “I don’t know who you are”.
I know you, but you can’t have the requested resource.
I’m not sure what you were trying to do because this resource doesn’t exist.
Wait… something went wrong. I don’t feel well.
We have used a few different HTTP response headers.
| header | example values | Purpose |
|---|---|---|
| “Content-Type” | “text/html”, “text/plain” | Specifies the media type of the response body. |
| “Content-Length” | “1024”, “0” | Indicates the size of the response body in bytes. |
| “Location” | “/”, “/login” | Provides the URL for redirection (used with 3xx codes). |
| “Set-Cookie” | “sessionId=abc123; Path=/”, “theme=dark; Max-Age=3600” | Instructs the client to set a cookie. |
Make sure you understand what each of these are for.
The POST method is not idempotent so successful requests must be handled carefully.
Successful POST requests cannot return simple HTML responses with 200 OK. If they do, then the browser can refresh to reissue the same request.
Unsuccessful POST requests can be reissued safely so they can return an HTML response.
A common solution is to return a 303 See Other and add a Location header with a path to a resource which shows the change.
They can return a failure status code (such as 400, 404, 401 etc) to explain why they didn’t work. The HTML response should include advice as to how the user should proceed.
A browser receiving a 303 See Other status code will look for the Location header and immediately issue a GET request, thus loading a new resource.
If you have any questions, now is a good time to ask.
Thanks for listening