HTTP is the protocol that powers the Web. It was originally designed in 1996 for transferring and manipulating simple text-based documents (mainly hypertext resources).
Nowadays it’s been adopted for many different purposes. It’s used for: multimedia content transfer, rich real-time session-based web applications, API messages dispatch, Internet of Things and much more.
For this reason, the HTTP specifications are continuously updated, by adding new features and improving performance.
In May 2015, the latest version 2.0 was standardized with RFC 7540.
This introduced major differences on how the low-level protocol works.
From the application perspective, very little has changed: requests, responses, resources, headers and HTTP methods are still there.
New features have been added such as the possibility to push resources to the client.
The lesson we learned with REST
For many developers, nowadays, building an API for their applications essentially means mapping the resources of the domain to URIs, with the REST principles in mind.
Usually creating a RESTful system is not difficult, and the simplicity of the idea makes the task easier.
Let’s see some of the consequences and benefits of choosing REST:
- Every HTTP verb has its own meaning, allowing the developer to understand immediately what kind of operation (typically among the CRUD ones) is going to be performed on the resource identified by the URI.
- Often the same URI can be used with multiple verbs to accomplish different tasks (e.g. “example.com/tag/123” refers to a particular tag that you can retrieve, update or delete).
- Controllers in many server-side frameworks can be created with a RESTful approach, each one of them representing one or more resources.
However, unfortunately, it’s often easy to come across some problems:
