Gain an understanding of the REST architectural style for web services, as well as its motivation. Design and document a RESTful API, and learn the differences between it and GraphQL .
Examples
Exercises
Context
In a distributed system, multiple systems must communicate with one another. On the web, a client (e.g. a browser or a server) wants to communicate with a server (e.g. a web service). To facilitate this, the server provides an application programming interface (API). These APIs can be implemented using various architectural styles and technologies.
The Request-Response Pattern is a communication pattern between two systems, where one system (the client) sends a request to the other system (the server) and the server responds with a response. This pattern is the basis for communication between a client and a server in a distributed system. The request contains information about the operation that should be performed and the parameters for the operation. The response contains the result of the operation. The request-response pattern is synchronous, which means that the client blocks until the server sends a response.
REpresentational State Transfer
REST stands for REpresentational State Transfer. It is an architectural style for web services. If a web services complies to the REST architectural style, it is said to be a RESTful web service.
The concept of REST was introduced and and defined by Roy Fielding in his PhD Dissertation, 2000 (fielding00). However, there is no official standard for REST.
A web service typically hosts many entities such as users and products. The entities are resources with a textual representation. A single resource can have multiple representations for different formats:
The textual representation of a user entity with the id “alice” in the format application/json could look like this:
{
"id": "alice",
"name": "Alice"
}
The textual representation of the same user entity in the format application/xml could look like this:
<user>
<id>alice</id>
<name>Alice</name>
</user>