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 a website. In a sense, REST is an architecture that focuses on compatibility and efficient interaction with other network nodes and client software. For them, the website is a black box that implements the HTTP interface.

Unified Software Interface


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 request is a request whose effect of repeated execution is equal to the effect of a single execution.

Correspondence table of the HTTP security method and idempotency:
HTTP MethodSafeIdempotent
GetYesYes
HEADYesYes
OPTIONSYesYes
PutNotYes
DELETENotYes
PostNotNot
What do we see? A GET request should not change the state of the resource to which it is applied. PUT and DELETE requests can change the state of the resource, but they can be safely repeated if there is no certainty that the previous request has been completed. In principle, this 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 non-idempotent. 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. In essence, it corresponds to the operation of adding new elements to the collection: they executed the request X times, and X elements were added to the collection.

Based on the concepts of security and idempotency, it is easier to understand which methods correspond to operations in CRUD terms:
HTTP methodOperation
PostCreate
GetRead
PutUpdate
DELETEDelete
What follows from this? When designing a REST interface, you first of all need to think, not about how the URL structure will look, but whether the essence of the performed security operations and the idempotency of the selected HTTP method are appropriate.

Ignoring the principles of security and idempotency can lead to all sorts of errors and strange effects. If any GET request handler performs an unsafe operation, even a regular search robot can provoke repeated execution of this unsafe operation.

Failure to store client state and caching

If during page rendering we display the user’s name, his basket with goods, a list of recently viewed goods in the side column, then this page is much more difficult to cache in such a way that the cache is useful to all visitors to the site, and not just this particular one.

Moreover, the internal logic is complicated: you have to use sessions. Each time a page is generated, it is necessary to initiate the loading of session data from the repository, and the saving of session data to the repository. All this translates into active reading and writing to disk or to the database. Often a website is designed in such a way that when visited by a search robot, it still starts a session for it, although there is no point in this.

REST offers us to refuse or minimize the storage of client status on the serverby transferring data from the session to the database and to the client side. For example, we could store the list of viewed goods in cookies, the user's basket in the database, and load blocks that could not do without the state of the client in separate requests so that they would 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 vast majority of cases, you can do without complicated internal logic with caching individual SQL queries or individual page blocks via memcache.

REST offers us to use HTTP headers to control caching. This allows you to transfer the burden of cache storage to the client, to intermediate nodes between the server and the client, or to specialized software, for example, Squid.

Not entirely 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 moved, and will not request it anymore
  • 400 (Bad Request) . User sent incorrect data. If he sends the same data next time, the result will be the same error. You can set a caching header for it, 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 support is not planned in the near future
  • 410 (Gone) . The situation is the same as with 404.

I hope I managed to interest you in a deeper study of the HTTP protocol and REST architecture. There are good books, such as the RESTful Web Services Cookbook. Good luck and thanks for the time spent on the article!

Also popular now: