One of the hottest topics for discussion today is the new HTTP/2 that is the most substantial protocol update since 1999, the year when the HTTP/1.1 version was released.
Among the key improvements brought by HTTP/2 are multiplexed streams, header compression, server push, and a binary protocol instead of textual one. These and other positive changes allowed to achieve good web pages loading results, including those having lots of additional files attached to them (e.g. styles, scripts, images, fonts, etc.). But what effect is this going to have upon REST APIs and their work?
The first thing to talk about is the format of data transmission. As has been mentioned above, a binary format has substituted a textual one which is good news for servers but not for developers. The latter one is convenient for program debugging but the binary one is still a good innovation, as it is much easier for a computer to process such data. Consequently, the binary format will contribute to lightening some of the server processor load, which would be helpful for heavily loaded REST APIs.
The protocol is compatible with the HTTP/1.1 version. Status codes, methods, and headers did not overcome any changes. The only thing that did change is the way of transmitting data via TCP connection.
HTTP/2 is much more effective when it comes to processing a large number of requests. One of the biggest HTTP/1.1 problems is that separate requests are expensive. The reason for this is that many TCP connections are created, and these are established due to the “3-way handshake” method. Then some time has to pass for âslow startâ algorithm to make the connection effectively fast. HTTP/2 is devoid of such a drawback thanks to multiplexed streams. This allows making several HTTP requests as if they were made concurrently. Therefore, all the styles, scripts and images will load faster and users will certainly notice the speed increase. Although in REST APIs there is no need to load a few files simultaneously, multiplexing will let to perform a number of concurrent server requests more effectively due to one TCP connection being used for all these requests. This will also lighten the server load, as there will be no necessity to allocate resources to maintain more than one TCP connection, which will save some memory though the work of processor will be a little bit more intensive.
One more improvement that came with HTTP/2 is header compression. API requests usually have much less headers than ordinary web pages. That is why the benefits it may bring are most likely to be minor.
“Server push” technology made it possible for server to initiate data transmission. Here is an example. A client requests a web page. The web server processes the request and, as a result, gets an idea of what resources the client needs additionally and thus can send them right after the response with the document. This way, the client does not need to send additional requests to get the additional resources mentioned above. Unfortunately, it is difficult to find a RESTful API service where this technology can be truly useful.
Though many changes brought with HTTP/2 were created to speed web browsing up, some of them can be used in the world of REST APIs as well. It is possible to achieve greater efficiency at a lower cost if the HTTP/2 strong points are taken into consideration when designing an application.
In case you are a B2B SaaS provider who works with eCommerce, then shopping cart integrations are a vital part of your business. The easiest way to integrate with multiple eCommerce platforms is through a unified API provided by API2Cart. The service allows to connect to 40+ shopping carts and marketplaces via only one API. You will be able to work with orders, products, customers, categories, shipments and other needed store data.
If you have any questions feel free to contact us or register a Free 30-days account right now.
