Imagine if every PhD dissertation resulted in something that changed the world? Sadly, most end up with a copy on the shelf at the university library, maybe one in the author’s office, and little more. But one, about 16 years ago, led to the foundation of that thing we spend our lives on — the Web. Back in 2000, Roy Fielding presented his doctoral dissertation at University of California-Irvine on the representational state transfer.
Representational state transfer or “REST” is the software architectural style designed for distributed systems and, particularly, the World Wide Web. Throughout this REST API tutorial, you will find the same refrain: REST is not a protocol or standard. REST architecture is simply following certain guidelines for how a well-designed Web app behaves, in a logical organization that involves a series of links — or state transitions — that then result in the next page —representing the next state of the application — for the user.
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!
REST Deserve The Best
ReadyAPI provides the industry's most comprehensive and easy-to-learn functional testing capabilities for REST APIs. Based on open core technology proven by millions of community members, ReadyAPI helps you ensure that your APIs perform as intended, meet your business requirements, timeframes, and team skill sets right from day one.
Learn More: