Appendix C. A quick introduction to HTTP

HTTP is the communication protocol that web applications use to let a client and server exchange information in a structured way. It is designed as a stateless, text-based request-response model, which means each request stands on its own and the data is exchanged as plain text. For developers building web apps with Spring, understanding these basics is enough to follow the examples and work effectively without needing to memorize the full HTTP specification.

An HTTP request is made up of a mandatory URI and method, plus optional parameters, headers, and body content. The URI identifies the resource the client wants to work with, while the method describes the action to take, such as GET for reading data, POST for creating data, PUT for replacing data, and DELETE for removing data. Other methods like OPTIONS and PATCH appear less often but still matter, and the choice of method should match the intended behavior of the operation. Small pieces of data are commonly sent as request parameters or headers, while larger payloads are placed in the request body.

An HTTP response always includes a status code, and may also include headers and a body. Status codes beginning with 2 indicate success, 4 indicate a client-side problem such as a bad request or missing resource, and 5 indicate a server-side failure. Because HTTP is stateless, servers sometimes use sessions to remember information across multiple requests from the same client, such as items added to a shopping cart. A session is identified with a session ID and lasts only for a limited time before a new one must be created.

Figure C.1 HTTP is a protocol that describes how a client and a server talk. HTTP assumes a client makes a request, and the server responds. The protocol describes what the client’s request and the server’s response look like. HTTP is stateless, meaning the requests are independent of one another, and text-based, which means the information is exchanged as plain text.

Figure C.2 The HTTP request URI identifies the resource the client requests to work with. The first part of the URI identifies the protocol and the server that runs the server app. The path identifies a resource exposed by the server.

Figure C.3 For an online shop, the backend needs to identify the clients and remember the products they added to their carts. The HTTP requests are independent one from another, so the backend needs to find another way to remember the products added by each client.

Figure C.4 The HTTP session mechanism. The server identifies the client with a unique session ID it generates. The client sends the session ID in the next requests, so the backend app knows which memory location it reserved earlier for the client.

FAQ