Introduction to REST services
In this article I am going to discuss about REST services.
What is REST?
The REST architectural style is designed specifically for network-based client-server applications. REST stands for Representational State Transfer Protocol. It is a software architectural style that was created to guide the design and development of the architecture for the WWW. This was introduced and defined in 2000 by Roy Fielding. RESTful services are resolve around resources. Resources are identified by URIs. Multiple URIs can refer to the same resource. The underlying protocol for REST is HTTP. Different HTTP verbs/methods used to perform different operations on the same resource. REST uses various representations to represent a resource like text, JSON, XML. JSON is the most popular one and JSON or XML is used to pass data between client and server.
WHY Use REST?
· REST is very lightweight, scalable, and maintainable.
· Restful services became most popular because of its heterogeneous nature. It offers flexibility to applications built on various programming languages and platforms to communicate with each other.
· RESTful services make it easier to communicate with applications despite of the devices.
· Since all Cloud-based architectures work on the REST principle, web services that are programmed on the REST services, can make the best use of Cloud-based services.
Key elements of REST
Below are some key elements used in the REST.
Resources: REST is resource-based service. Resources are identified using URI.
Request verbs: these are HTTP verbs used to perform different operations on the resources.
Request Headers: These are the additional instructions sent with the request such as required response type and authorization details.
Request Body: it is the data which is sent with the request.
Response Body: This is the main body of the response. This might be an XML or JSON document with the requested information.
Response Status codes: These are the general codes which are returned along with the response from the web server indicating its status. Following are some commonly used HTTP status codes.
· 200 — OK
· 201 — Created
· 202 — Accepted
· 302 — Found
· 304 — Not Modified
· 400 — Bad Request
· 401 — Unauthorized
· 403 — Forbidden
· 404 — Not Found
· 500 — Internal Server Error
· 502 — Bad Gateway
· 503 — Service Unavailable
RESTful methods/ HTTP verbs
These methods used to perform different operations on the resources.
GET — used for fetching a resource
POST — used for inserting a new resource
PUT — used for replacing an existing resource
PATCH — used for updating a resource
DELETE — used for removing a resource
OPTIONS — used for getting all allowed options
HEAD — used for getting only the response header
REST Architectural constraints
There are 6 constraints defined on the RESTful architecture. A system that complies with these constraints is loosely referred to as RESTful.
· Uniform interface
The uniform interface constraint is fundamental to the design of any RESTful system. This is the underlying technique of how RESTful web services should work. It is based on the HTTP specification.
There are 4 constraints for this uniform interface
1. Resource identification in requests: resources are identified using URIs. The resources themselves are conceptually separate from the representations that are returned to the client. For example, the server could send data from its database as HTML, XML or as JSON and none of which are the server’s internal representation of data.
2. Resource manipulation through representations: When a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource’s state.
3. Self-descriptive messages: each message contains sufficient information for a particular operation
4. Hypermedia as the engine of application state (HATEOAS): use hypermedia to better navigation through resources and use hyperlinks to navigate to related resources.
· Stateless
No client state is saved on the server. Session state will only be kept in client side. This is ideal for high volume applications, increasing performance by removing server load caused by retention of session information.
· Client- Server architecture
It means that the server will have a RESTful web service which would provide the required functionality to the client. This use URI to make the connection between the client and the server. The client send’s a request to the web service on the server. The server would either reject the request or comply and provide an adequate response to the client.
This clearly separates user interfaces and services. Client is portable and does not have any connection to data server as well as server stays independently from different user interfaces.
· Layered System
The concept of a layered system is that any additional layer such as a middleware layer can be inserted between the client and the actual server hosting the RESTful web service. Client only knows the URI and does not see the underlying layers or complexities of the service. This increases the scalability by enabling load balancing and by providing shared caches.
· Cacheable
REST services should be cacheable. clients and intermediaries can cache responses (resources returned from the server). Responses must, implicitly or explicitly, define themselves as either cacheable or non-cacheable to prevent clients from providing stale or inappropriate data in response to further requests. Well-managed caching partially or eliminates some client–server interactions, further improving scalability and performance.
· Code on demand
This is considered as an optional constraint. Server has the luxury to transfer some parts of its logic to the client.
REST Architectural properties
The constraints of the REST architectural style affect the following architectural properties.
· performance in component interactions
· scalability allowing the support of large numbers of components and interactions among components
· simplicity of a uniform interfaces
· modifiability of components to meet changing
· visibility of communication between components by service agents
· portability of components by moving program code with the data
· reliability in the resistance to failure at the system level in the presence of failures within components, connectors, or data.
Conclusion
In this article I have presented what is REST services, usage of REST services and behavior of REST services.
