From time to time I have to talk about HTTP. Both programmers and testers. This is a short summary of such stories with a mention of some additional topics that would also be nice to study. The main goal is to provide maximum practical knowledge, which is enough for 99% of practical situations.

HTTP works with “resources”. For simplicity, you can think that these are files. For example, GET /books/123/authors.json?limit=2&page=2 you can understand how to get the authors of the book ID 123 in JSON format from the second page if the page size is 2 authors. This is a Restful style, it is considered “correct”, but it does not always fit. It is most often used for data access (CRUD scripts). When the application mainly works with commands, the style is slightly different (for the same example): GET/api/authorsList?book=123&limit=2&page=2. In practice, there are many more such APIs, because and there are not so many CRUD scripts, and the approach itself is closer to the server code. It would be nice to read about Restful APIs someday and use them for business.

An HTTP request is a text (except sometimes except for the request body) and consists of (in the order of appearance in the request):

  1. Verb (GET, POST, …)
  2. URI (/my/lala?a=b&page=2&page=3) – usually there is a host in the headers, and we know the port in advance, because we started on it. It has a length limit, but it is unclear what (depends on the browser, server and intermediate proxies). 16k is more or less safe. It is completely safe for 1k.
  3. Headings are not required
  4. The request body is not required, and for some verbs it is not allowed

The HTTP response is very similar to the request (response code, headers and body), at this level we will only analyze the response codes separately:

  1. 200 – everything is fine
  2. 201 – a new resource has been created (for restful style)
  3. 301 – the resource has moved to a new address forever (the address will be in the Location header)
  4. 302 – the resource has moved to a new address temporarily
  5. 404 – resource not found (sometimes it means 401/403 for secrecy)
  6. 401 – you need to log in
  7. 403 – logged in, but not enough rights (or not logged in)
  8. 422 – the server does not like the parameters, it cannot respond (request error)
  9. 500 – the server is bad (server error)
  10. 502, 503, 504 – something is wrong with the infrastructure (server error, but not the application itself)

Under what codes does it make sense to repeat the request? 5xx, with the rest, the answer is unlikely to change. It is better to repeat with delays. Or not to repeat it and leave it to the user (he will decide when to repeat it and whether it is worth it - maybe he will contact support or wait an hour).

There are 2 styles of error handling (essentially similar to restful and procedural):

  1. we give as many different response codes as possible so that it is already clear at this level what is happening
  2. If technically we received the request and fulfilled it, we always return 200. But whether it’s an error or not, it’s inside the JSON response. That is, we treat HTTP as some kind of transport protocol for remote method invocation and don’t really go inside it.

Verbs:

  1. GET – receiving, one of the main ones, there is no request body, should not change the data on the server
  2. POST – send an entity to a specific resource (in restful, a new resource will appear on the subpath, for example)
  3. PUT – replace the specified resource with a new entity
  4. PATCH – partial modification of the specified resource
  5. HEAD is a GET without a response body (if only headers are needed, for example, the size or when the resource was last modified)
  6. DELETE – deletes the resource
  7. OPTIONS – find out which verbs are supported by the specified path. In practice, it is usually used because of CORS (restricting access from one web page to another due to security).
  8. CONNECT – to establish a two-way connection with the server, for example, HTTPS (opens an encrypted channel)
  9. TRACE – haven’t seen anyone use it

URI:

  1. path (/mylala)
  2. query params (a=[b], page=[2,3]) – arrays of values in theory can be passed as repeats of parameters, but how to interpret it remains at the discretion of the server

Headlines:

  1. They can be any, consider the most important
  2. Host – specifies the DNS name, because the connection is made by IP and by another server that serves several sites will not understand which one to give
  3. Content-Type – the data type of the resource
  4. Content-Length – the size of the resource
  5. Authorization – is transmitted as we logged in to the server (usually this is sent by the application, the web page is authorized through cookies or URIs)
  6. Cookies – famous cookies (parameters that the browser stores between requests – usually for authorization or surveillance)
  7. Set-Cookie – response header: tells the browser to remember the new cookie parameter
  8. Accept – what type of resource we want to get (for example, sometimes you can get the same data in XML, JSON, CVS, XLSX formats)
  9. Location – usually in the answers it says where the resource is (codes 3xx and 201)
  10. Content-Range – get a piece of the resource
  11. Referer – browsers tell you from which page they are making a request or from which they went to this page
  12. Upgrade – offers a transition to other protocols, for example, WebSocket or HTTP/2.0
  13. Cache-Control, Age, Date, Digest, ETag, Expires, If-Match, If-Modified-Since, If-None-Match, If-Range, If-Unmodified-Since, Last-Modified – manage caching (if you are interested, you can easily find the corresponding article on the Internet about them – you need to choose the right option according to your case)

Request Body:

  1. The verbs GET, HEAD, CONNECT, OPTIONS, TRACE are missing
  2. The content type is determined by the Content-Type header
  3. Popular types: application/json, multipart/form-data (these are standard forms from HTML), but can be any

You can describe the HTTP API using OpenSpec (aka Swagger). It is good if the server automatically correctly generates such a description - the best protection against obsolescence. HTTP clients can also be generated from it. It is worth noting that the type of response body in OpenSpec depends on the http code (200, 404, …): according to the description, there cannot be 2 different schemes for one code. It’s worth reading more about OpenSpec in other places sometime.

You can view the requests in the browser in the developer plugin. For more complex cases (the server sends requests or a mobile application), you can use Charles (or analogues).

If you run queries, many people like Postman (in particular, the ability to transfer a collection of queries to another person). Personally, I like httpie better. Postman is more suitable for testers (there are a lot of requests, they are used and stored a lot), httpie for programmers (I did and quickly forgot).

In addition to the request-response over HTTP, two-way communication between the server and the client can be organized. This is a lot of magic, the main technology is WebSocket, but usually it’s all heavily wrapped and does not require much understanding from beginners.

Although this is a rather strong simplification, it turned out quite a lot.