The labs on this site need JavaScript to run. The same content is written out below.

Learn › Networking › HTTP

HTTP messages and status codes

This is what a request and a response look like as text

The HTTP messages that a browser and a server exchange are text with a fixed shape. A request has "what" (the address) and "how" (the method) on its first line, and a response has "how it went" (the status code) on its first line.

Partly checked against real execution · The message structure was checked against real raw text, and the status codes are based on the standard

Concepts in this lab

HTTP as a stateless protocol

HTTP is a communication protocol in which a client sends a request and a server responds. Stateless means that the server does not remember the content of earlier requests, so each request must carry all the information needed to process it. Because the server keeps no state, any server can take a request, which makes it easy to add servers. Information that must carry over, such as a login state, is kept with cookies, sessions, or tokens.

HTTP methods

The part of an HTTP request that indicates the action the request wants to perform on a resource. GET means read, POST means create or a processing request, PUT means replace the whole resource, PATCH means modify part of it, and DELETE means delete. Use each one according to its meaning so that HTTP behavior such as caching and retries works as expected.

HTTP status codes

A three-digit number that shows the result of the server's handling of a request. 2xx means success, 3xx means a move to another location (redirection), 4xx means a problem with the client's request, and 5xx means an error on the server side. Common ones are 200 (success), 201 (created), 400 (bad request), 401 (authentication required), 403 (no permission), 404 (not found), and 500 (server error).

REST

An architectural style in which resources on the web are identified by URIs, actions on those resources are expressed with HTTP methods, and representations of the resources (such as JSON) are exchanged. Its characteristics are that it is stateless, meaning the server does not store the client's state, and that it has a uniform interface. In practice, an HTTP API designed according to these principles is called a REST API.

URI and URL

A URI is a string that identifies a resource, and a URL is a URI that identifies the resource by its location (how to access it and its address). Most addresses used on the web are URLs, and every URL is a URI.

Try these

• Default settings — A successful read. The response comes with 200 and a body.
• Create a new order — The response is 201, and it tells you the address of the newly created order.
• Invalid request — 400. The sender has to fix it.
• Not logged in / No permission — Switch back and forth to see the difference between 401 and 403.
• Order that does not exist — 404. There is nothing at the address.
• Server error — 500. The server has to fix it, not the sender.

Running with the default settings

1. This is the first line of the request, the start line. It holds the method GET, the target path /orders/1, and the protocol version, in that order. The method says "what to do", and the path says "what it is about".
2. The next lines are headers. Each one is written as "name: value" and carries extra information about the request. Host says which site the request is for, Authorization says who is sending it.
3. An empty line marks the end of the headers. This request has no data to send, so it has no body. The server has to be able to handle the request by looking at this one request alone, because it does not remember the requests sent before it (it is stateless).
4. This is the response from the server. The status code 200 OK is on the first line. The first digit of the three-digit number is the broad category: 2xx Successful.
5. The server finds the requested order and returns it in the body.

Result of this run

• The first digit of the status code alone tells you how to respond. With 4xx, the request usually has to be fixed (a few, such as 408 and 429, can succeed if you send the same request again after a short while). 5xx is a problem on the server side, so you can try again after a short while. Monitoring also counts 4xx and 5xx separately.
• An HTTP message has four parts: the start line, the headers, an empty line, and the body. The start line of a request holds the method and the path, and the start line of a response holds the status code.

Code

@GetMapping("/orders/{id}")
OrderDto get(@PathVariable long id) {
    return orderService.find(id);                 // 200 OK + JSON body
}

Assumptions of this model

The structure of the messages (start line, headers, empty line, body) is exactly the shape seen in the raw text exchanged between a real HTTP server and a socket, and only the main headers are kept on screen. The status code for each situation follows the definitions in the HTTP standard (RFC 9110) and the conventions widely used in REST APIs. Some designs return 404 instead of 403 for a request about another user's resource, to hide that the resource exists.

Previous lab: Flow control and congestion control · Next lab: HTTP/1.1, 2, 3