How REST-architecture affects the speed and reliability of the site
The REST architecture is based on several important basic principles that are often overlooked by novice programmers. Meanwhile, these principles are critical to the speed and reliability of the website. In a sense, REST is an architecture that focuses on interoperability and efficient interaction with other network nodes and client software. For them, the website is a black box that implements the HTTP interface.
The key point: compatibility with HTTP methods in terms of security and idempotency.
A secure request is a request that does not change the state of the application.
')
An idempotent query is a query whose effect from multiple execution is equal to the effect from a single execution.
HTTP table of security method and idempotency:
What do we see? A GET request must not change the state of the resource to which it applies. PUT and DELETE requests can change the status of the resource, but they can be easily repeated if there is no certainty that the previous request was executed. In principle, it is logical: if you repeatedly repeat the request to delete or replace a specific resource, the result will be the removal or replacement of the resource. But the POST request, as we see from the table, is unsafe and nonidempotent. That is, not only does it change the state of the resource, but its repeated repetition will have an effect depending on the number of repetitions. It corresponds to the operation of adding new items to the collection: executed the query X times, and X items were added to the collection.
Based on the concepts of security and idempotency, it is easier to understand exactly which methods correspond to operations in terms of CRUD:
What follows from this? When designing a REST interface, one should first of all think about what the structure of the URL will look like, but whether the essence of the performed operations of security and idempotency of the selected HTTP method corresponds.
Ignoring the principles of safety and idempotency can lead to all sorts of errors and strange effects. If any GET request handler performs an unsafe operation, even an ordinary search robot can provoke repeated execution of this unsafe operation.
Failure to store client state and caching
If during the page rendering we display the user’s name, his cart with goods, the list of recently viewed products in the sidebar, then this page is much more difficult to cache so that the cache is useful to all site visitors, and not just this one.
Moreover, the internal logic is complicated: you have to use the session. Each time a page is generated, it is necessary to initiate the loading of session data from the repository, saving the session data to the repository. All this translates into active reading and writing to disk or in the database. Often the website is designed in such a way that when you visit a search robot, it will still start a session for it, although there is no sense in it.
REST suggests us to refuse or minimize client state storage on the server by transferring data from the session to the database and to the client side. For example, we could store the list of viewed products in cookies, the user's basket in the database, and blocks that cannot do without the client's state in any way, load individual requests so that they do not interfere with caching the rest of the page.
This allows you to cache most pages completely for a long time, relying on the capabilities of the HTTP protocol. In the overwhelming majority of cases, you can do without complex internal logic with caching individual SQL queries or separate blocks of a page through memcache.
REST suggests us to use HTTP headers to control caching . This allows you to transfer the burden of storing the cache to the client, to intermediate nodes between the server and the client, or to specialized software, such as Squid.
Not quite obvious, but you can cache not only successful HTTP responses (200 OK), but also others:
I hope I managed to get you interested in learning more about the HTTP protocol and REST architecture. There are good books, for example, the RESTful Web Services Cookbook. Good luck and thank you for your time spent on the article!
Unified software interface
The key point: compatibility with HTTP methods in terms of security and idempotency.
A secure request is a request that does not change the state of the application.
')
An idempotent query is a query whose effect from multiple execution is equal to the effect from a single execution.
HTTP table of security method and idempotency:
| HTTP Method | Safe | Idempotent |
|---|---|---|
| Get | Yes | Yes |
| HEAD | Yes | Yes |
| OPTIONS | Yes | Yes |
| PUT | Not | Yes |
| DELETE | Not | Yes |
| POST | Not | Not |
Based on the concepts of security and idempotency, it is easier to understand exactly which methods correspond to operations in terms of CRUD:
| HTTP method | Operation |
|---|---|
| POST | Create |
| Get | Read |
| PUT | Update |
| DELETE | Delete |
Ignoring the principles of safety and idempotency can lead to all sorts of errors and strange effects. If any GET request handler performs an unsafe operation, even an ordinary search robot can provoke repeated execution of this unsafe operation.
Failure to store client state and caching
If during the page rendering we display the user’s name, his cart with goods, the list of recently viewed products in the sidebar, then this page is much more difficult to cache so that the cache is useful to all site visitors, and not just this one.
Moreover, the internal logic is complicated: you have to use the session. Each time a page is generated, it is necessary to initiate the loading of session data from the repository, saving the session data to the repository. All this translates into active reading and writing to disk or in the database. Often the website is designed in such a way that when you visit a search robot, it will still start a session for it, although there is no sense in it.
REST suggests us to refuse or minimize client state storage on the server by transferring data from the session to the database and to the client side. For example, we could store the list of viewed products in cookies, the user's basket in the database, and blocks that cannot do without the client's state in any way, load individual requests so that they do not interfere with caching the rest of the page.
This allows you to cache most pages completely for a long time, relying on the capabilities of the HTTP protocol. In the overwhelming majority of cases, you can do without complex internal logic with caching individual SQL queries or separate blocks of a page through memcache.
REST suggests us to use HTTP headers to control caching . This allows you to transfer the burden of storing the cache to the client, to intermediate nodes between the server and the client, or to specialized software, such as Squid.
Not quite obvious, but you can cache not only successful HTTP responses (200 OK), but also others:
- 301 (Moved Permanently) . Resource changed address. We can set a caching header here and the user will remember where this resource has moved and will not request it anymore.
- 400 (Bad Request) . The user has sent invalid data. If he sends the same data next time, the result will be the same error. You can set him a caching header, and the request will not be repeated.
- 404 (Not Found) . Resource is missing. If it does not appear for a long time at this address, you can set a caching header to prevent repeated requests from this client.
- 405 (Method Not Allowed) . HTTP method is not supported. You can set a caching header if its support is not planned in the near future.
- 410 (Gone) . The situation is the same as with 404.
I hope I managed to get you interested in learning more about the HTTP protocol and REST architecture. There are good books, for example, the RESTful Web Services Cookbook. Good luck and thank you for your time spent on the article!
Source: https://habr.com/ru/post/251669/
All Articles