RESTful Web Services Architecture
What is REST ?
REST is an abbreviation for Representational State Transfer.
A simple definition of REST could be something like-
Examination of the Internet as a stateless service of near-limitless expansion model with a simple but effective information delivery system.
Sites Using REST Architectural style
Amazon, Yahoo, Google (Search), Flickr, Facebook, Myspace, LinkedIn, Microsoft, Ebay etc?
Definition
REST is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through an application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.
– Roy Fielding in his Ph.D. dissertation in the year 2000
What is the REST style?
REST is often described as an architecture style.
It can be described as Set of formal and informal guides to creating architectures ? ?constraints?
- Client-server
- Stateless
- Cacheable
- Uniform interface
- Layered system
- Code on demand (optional)
When we use REST style an Application can interact with resource by knowing only two things :
- Identifier of the resource
- Action to be performed on the resource
Understanding Constraints of REST style Architecture
1. Client Server
Separation of concerns is the principle behind the client-server constraints. By separating the user interface concerns from the data storage concerns, we improve the portability of the user interface across multiple platforms and improve scalability by simplifying the server components.
Client Server Model
2. Stateless
Statelessness means communication must be stateless in nature as in the client stateless server style, i.e. Each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client.
Client Stateless Server
3. Cacheable
In order to improve network efficiency, cache constraints are added to the REST style.
Cache constraints require that the data within a response to a request be implicitly or explicitly labeled as cacheable or non-cacheable. If a response is cacheable, then a client cache is given the right to reuse that response data for later, equivalent requests.
The advantage of adding cache constraints is that they have the potential to partially or completely eliminate some interactions, improving efficiency, scalability, and user-perceived performance by reducing the average latency of a series of interactions.
4. Uniform interface
The central feature that distinguishes the REST architectural style from other network-based styles is its emphasis on a uniform interface between components.
Resources are just concepts located by URIs. URIs tell client that there?s a concept somewhere. Client then asks for specific representation of the concept from the representations the server makes available.
E.g. Web Page is a representation of a resource
5. Layered system
In order to further improve behavior for Internet-scale requirements, we add layered system constraints.
The layered system style allows an architecture to be composed of hierarchical layers by constraining component behavior such that each component cannot ?see? beyond the immediate layer with which they are interacting.
6. Code on demand
The final addition to our constraint set for REST comes from the code-on-demand style.
REST allows client functionality to be extended by downloading and executing code in the form of applets or scripts.
This simplifies clients by reducing the number of features required to be pre-implemented. Allowing features to be downloaded after deployment improves system extensibility.
Creating a RESTful service
Steps
- Define the domain and data.
- Organize the data into groups.
- Create URI to resource mapping.
- Define the representations to the client (XML, HTML, CSS, ?).
- Link data across resources (connectedness or hypermedia).
- Create use cases to map events/usage.
- Plan for things going wrong.
I hope this helps understanding REST style architecture. Stay tuned. Next article is going to be writing web services (REST APIs) using different technologies (Python Flask, Node Express, Java, Golang).
){kind=link}
){kind=link}