A RESTful web service is able to scale well partially because it can take advantage of the caching by clients and intermediate nodes that is provided out of the box by HTTP.
This caching can only be achieved by requiring cacheable request types to be idempotent (produce the same result when called multiple times), and by requiring that the server be stateless (i.e., not generate responses based on session/per-connection state). When these constraints apply, all information that determines a response is contained in the request, and so intermediate nodes such as proxies can safely return cached results, provided that the request is the same, without knowing anything else about the end server.
Similarly, idempotence allows for actions be performed multiple times, such as in the case of a failed connection, without fear of adverse effects. This is particularly useful not only for GET requests, but for PUT and DELETE requests, which allow for clients to predictably re-request for a change on the server.
A RESTful web service, by virtue of not generating responses based on per-connection state, also only needs to scale its usage of hardware resources with the data provided by the service, not based on the number of concurrent connections.
A RESTful web service is able to be extended dynamically, with minimal coordination between the client and server, because resources are discovered dynamically by clients. This is particularly a benefit over most RPC implementations, as even small changes in the interface to an RPC API can break clients.
This is achieved through the use of hypermedia formats - formats that contain links. If clients don't rely on being able to parse or compose URIs, and instead, sufficiently descriptive hypermedia formats are used, a server can add new features (resources) by simply describing and linking to them.
Similarly, as HTTP provides content negotiation, a RESTful API is able to support multiple representations of a resource - this allows for clients and servers to add and deprecate formats as they please, without breakage, so long as they continue to share at least one common media type. This is particularly useful for extending beyond the capabilities provided by a particular media type.
Because clients and servers need to know nothing of eachother aside from a shared media type, they are completely decoupled from eachother, and so development of alternative clients is simplified - new clients need only support a shared media type. Servers may do their part in making client development easier by providing commonly implemented or well-specified media types that are easy to consume.
RESTful web services are also particularly easy to test. As with in purely functional programming, the removal of a degree of side effects provides for much more testable interfaces, as output is predictable, consistent, and requires no set-up.
Additionally, all RESTful web services can be tested at a high level with the same tools (e.g., curl). This benefit is primarily derived from resource-based addressing (URIs), and the fact that HTTP provides a standard generic interface for operating on those resources (HTTP verbs).
Add to Chrome
Add to Edge
Add to Firefox
Add to Opera
Add to Brave
Add to Safari