This week’s issue brings to you the following:
Understanding REST Headers
What is Cross-Origin Resource Sharing (CORS)?
What are the differences between HTTP/1, HTTP/2 and HTTP/3 protocols
So, let’s dive in.
BIG Announcement: I'm happy to announce a long-term cooperation with Postman!
This will enable me to focus more on my (writing) work, to make it more high-quality, and enable it to remain free for you.
Check out the new Postman's VS Code extension, which brings the Postman API Platform closer to developers' workflows within VS Code—now with expanded functionality supporting collections and environments. Over 135,000 developers have installed the Postman VS Code extension since it was unveiled this summer, and it's a featured choice on Microsoft's VS Code Marketplace.
Understanding REST Headers
The Hypertext Transfer Protocol (HTTP) header is a component of HTTP and transmits extra data during HTTP requests and responses. The server uses the HTTP header and the browser to share metadata about the document and the data sent to the browser by the web server called the website.
There is a variety of data in the REST headers that can be used to trace problems as they arise. As they show the meta-data related to the API request and response, HTTP Headers play a significant role in the API request and response. Headers contain data for:
Request and Response Body
Request Authorization
Response Caching
Response Cookies
Also, to the categories mentioned above, HTTP headers contain information about different HTTP connection types, proxies, etc. Most headers maintain connections between clients, servers, and proxies; thus, testing is unnecessary.
In general, we have request and response headers. We set a request header when sending a request to an API and get some headers with a response. The standard header structure is named name:value, but it can have many values separated using a comma.
Some standard headers are:
Authorization: which contains the client's authentication information for the requested resource.
Accept-Charset: This header instructs the server which character sets the client accepts and is charged with the request.
Content-Type: Specifies the response's media type (text/html or text/JSON), which will aid the client in processing the response’s body.
Cache-Control: The client may keep and reuse a cached response for the duration specified by the Cache-Control header. This is the cache policy set by the server for this response.
You can check the docs and HTTP protocol specs to learn more about HTTP headers.
What is Cross-Origin Resource Sharing (CORS)?
Browsers use CORS to prevent websites from requesting data from different URLs. A request from a browser includes an origin header in the request message. The browser allows it if it gets to the server of the exact origin; if not, the browser blocks it.
We can deal with CORS issues on the backend. Cross-origin requests require that the values for origin and Access-Control-Allow-Origin in the response headers match, and the server sets it. When you add an origin to the backend code, the CORS middleware only permits this URL to communicate with other origins and utilize it for cross-origin resource requests.
There are two ways to fix CORS issues:
Configure the backend to Allow CORS.
A server can let all domains with Access-Control-Allow-Origin: *. This turns off the same-origin policy, which is not recommended. Another option would be only to allow a particular domain, e.g., Access-Control-Allow-Origin: https://somedomain.com.Use a Proxy Server
We can use a proxy server to call external API. It acts as a middleware between the client and the server. If a server doesn't return proper headers defined by CORS, we can add them to the proxy.
The differences between HTTP/1, HTTP/2 and HTTP/3 protocols
HTTP (The Hypertext Transfer Protocol) is an application protocol used for communicating over the world wide web since its introduction in 1989. The first stable version of HTTP/1.1 was released in 1997 by IETF. Since then, it has become the de facto online communication norm. HTTP utilizes a few simple methods to send and receive information between computers. The two most common methods are GET and POST.
Yet, the Internet was changed a lot since 1997. and it demands more from HTTP/1.1. We now have rich websites, but also HD videos, etc. And we want all pages to load quickly, have better security, etc. HTTP/1 protocol had many issues, such as HOL problems, long HTTP headers, opening many TCP connections for more resources, etc. All this asked for a revision of this protocol, and IETF was published in 2015. a new version, called HTTP/2, which is the current version.
HTTP/2 introduces header field compression and permits many concurrent exchanges on the same connection, allowing for more effective use of network resources and decreased latency. It employs effective coding for HTTP header data and permits the interleaving of request and response messages over the same connection. Additionally, it enables prioritization of requests, enabling more crucial recommendations to finish faster and enhancing performance.
As a result, fewer TCP connections can be used than there were with HTTP/1.x, making the resulting protocol more network-friendly. Longer-lasting connections and reduced competition with other flows result from this, which improves the use of the network's capacity. Finally, HTTP/2 supports binary message framing, allowing more effective message processing.
Yet there were some issues with HTTP/2, such as TCP head-of-line blocking. Other notable problems with HTTP/2 include the Stream Reuse Attack and the Security Risk of HTTP/2 Flow Control.
The updated HTTP protocol, HTTP/3, was introduced in August 2020. and is based on the QUIC network protocol. This new version of HTTP was introduced to enhance HTTP/2 by sending encrypted data over UDP, and it seeks to make many significant advancements. HTTP/3 isn't meant to replace HTTP/2 completely; rather, it's intended to improve speeds when utilized in specific circumstances. HTTP/2 can always be used as a backup if HTTP/3 isn't available.
🎁 The Green IO podcast sponsors this week's issue. The place for responsible technologists to green their code one byte at a time.
Check the 21st episode Greening software 101 with Anne Currie - co-author of Building Green Software (O'Reilly) - and Arne Tarara - Green Coding Berlin's Founder, on your favorite podcast platform or here.
Great summary, thanks Milan.
While checking why the object storage service serving my Website didn't use HTTP/2, I learned most of major Web browsers allow HTTP/2 with HTTPS only. Encryption seems to have been a hot debate in the development of HTTP/2, and eventually it's not embedded in the protocol. Still, Web browsers optimize HTTP/2 efficiency by enforcing it on HTTPS only. I definitely understand the rationale, however it leaves out the edge case of small, cheap Websites hosted on object storage services not offering to use a Let's Encrypt certificate. Such Websites sound low-tech, and I believe they fit in the modern tech landscape.