8.1 Remote API approach
All programmers make the same mistake when building a client-server architecture. They begin to treat requests to the server as method calls .
You want to start the report generation process on the server, why not send it a request like:
http://server.com/startDocumentGeneration?paramsAnd how to download the report after it completes? To do this, we will write another method:
http://server.com/getDocumentThe server in HttpSessionstores information on our document, and as soon as the document is generated, the server will give it back.
Great approach. Or not?
The approach is really terrible. The thing is that the server must remember the document number. In other words, in order to properly process new method calls, the server must remember the results of calling previous methods.
On the web, this is a big problem. The Internet may disappear, the browser may close. The page can be reloaded or accidentally clicked on a link, and so on. And the server will continue to store megabytes of data from previous user requests ...
For comfortable work with the server, you cannot expect that you will always have the data of previous requests to the server at hand.
How then to call methods of the server? The correct answer would be terrible: no way!
8.2 REST approach
The programmers went back to basics and remembered that initially the request contained the path to the file on the server:
http://server.com/path?paramsAnd we decided to use this approach to the maximum.
Now the server is considered as a repository of data that is visible to the outside in the form of a tree .
If you want to get a list of all users, call the query:
http://server.com/usersIf you want to get data on user 113, run the query:
http://server.com/users/113And so on, all in the same vein.
Once again, the server is seen as a repository of data that is visible to the outside in the form of a tree.
Data can be received - GET requests , modified - POST request and deleted - DELETE request .
8.3 No state
The REST protocol of interaction between the client and the server requires the following condition: during the period between requests from the client, no information about the state of the client is stored on the server.
All requests from the client must be crafted in such a way that the server receives all the information it needs to fulfill the request each time . The session state is saved on the client side.
During the processing of client requests, the client is considered to be in a transitional state. Each individual application state is represented by links that can be invoked the next time the client hits.
8.4 Interface uniformity
All paths used to retrieve objects from the server are standardized. This is very convenient, especially if you are getting data from other REST servers.
All object interfaces must comply with three conditions:
Resource identification
All resources are identified in requests using a URI. The resources inside the server are separate from the views that are returned to the clients. For example, a server may send data from a database as HTML, XML, or JSON, neither of which is a storage type within the server.
Manipulating Resources Through a View
If the client stores a representation of the resource, including metadata, then it has enough information to modify or delete the resource on the server.
"Self-describing" messages
Each message contains enough information to understand how to handle it. For example, if you need information about the user, then the server will return you a JSON object, where there will be name, address fields.
There should not be a situation where the client needs to know that the first number in the response is the age, and the second is the date of birth.
8.5 Caching
The REST approach assumes that data requests are made via the HTTP protocol. Therefore, objects are obtained by calling a GET request. This means that they, like all resources received via a GET request, are subject to all the rules for caching HTTP resources.
That is, data received via the REST API is cached in the same way as any static resources on web servers. Beauty :)