REST architecture is inherently simple because it is based on seven descriptive properties:
REST architecture is inherently simple because it is based on seven descriptive properties:
- Performance - how components interact affects performance
- Scalability - able to support large numbers of components
- Simplicity - between interacting interfaces
- Modifiability - of components to meet changing needs
- Visibility - clear communication between components
- Portability - of the data-filled code
- Reliability - or resistance to fail at system level
A RESTful Web service also has to meet the following architectural constraints, which in turn allow it to have any or all of the desired properties mentioned above.
The uniform resource constraint is most inherent to being RESTful design. This constraint decouples and simplifies the REST architecture allowing it to scale and modify independently, increasing portability, visibility, and reliability of the components. The four constraints found within the uniform resource constraint are:
- Identification of resources as ‘requests’, in a simple way that is understood independent of original language or interpretation. (We’ll “get” more on this in a bit.)
- Manipulation of resources. When a client has a representation of data, it can then modify or delete that resource.
- Self-descriptive messages. Self-descriptive in itself; this kind of messaging is complete as an entity and in itself can describe how it can be processed.
- Hypermedia means that no other actions will be assumed besides those self-described.
If it doesn’t meet the uniform interface constraints nor the following constraints, it can’t be deemed a RESTful system:
- Client-server separation - These two are completely separate, enabling them to be developed and replaced independent of each other. Client code becomes more portable because it is separated from data storage, while the server becomes more scalable because it is unconcerned with user state or interface.
- Stateless - Each data request and response pair is treated as completely independent from prior and future requests. These states are “in transition” when one or more requests are outstanding.
- Cacheable - Everything on the Web can be cached, so responses must clearly define whether or not they are cacheable, avoiding either inappropriate caching or caching of old information.
- Layered systems - Intermediary servers must be available to make the system more scalable.
- Code on demand - This is the only “optional” REST constraint. Servers can temporarily extend or customize the functionality of a client by the transfer of executable code, like JavaScript.
Everything in the RESTful architecture is about resources.
A resource is an object with its own associated data. Resources have relationships with other resources and a set of methods or verbs to operate between these resources. Then you can have a collection of resources which can interact as a collection with one or more resources or collections. REST is simple as a concept because it follows a basic language of HTTP 1.1 hypertext transfer that the entire Web understands, namely the following, self-explanatory action verbs, which are usually written in capital letters to stand out:
- POST - to add data, like to a message board
- GET - to retrieve data, but without altering it, from a particular URL
- PUT - to save an update to the unified resource identifiers (URI)
- DELETE - to remove a specified resource
- PATCH - to make a change in a request
Now, with only these limited operations, REST simply focuses on interactions between data elements and on what roles components play, rather than focusing on details like language and implementations. REST became the basis on which HTTP standards and URIs were designed, which were also developed by Fielding in parallel. Bringing all three things altogether and REST easily became the prevailing and accepted software architectural style for the World Wide Web — not too shabby for a PhD dissertation!
Further Resources