Restful web Services

15 December 2017

REST(Representational State Transfer) is a simple scalable stateless architecture used in enterprise web applications that runs over HTTPS.

Constrains of REST

Restful web service has following constraints.

Stateless:
Stateless protocol is a communications protocol that treats each request as an independent transaction that is unrelated to any previous request so that the communication consists of independent pairs of request and response. A stateless protocol does not require the server to retain session information or status about each communications partner for the duration of multiple requests.

Client–server: A uniform interface separates clients from servers. This separation of concerns means that, for example, clients are not concerned with data storage, which remains internal to each server, so that the portability of client code is improved. Servers are not concerned with the user interface or user state for eg (UUI) , so that servers can be simpler and more scalable. Servers and clients may also be replaced and developed independently, as long as the interface between them is not altered.

Cacheable: Clients can cache responses. Responses must therefore, implicitly or explicitly, define themselves as cacheable, or not, to prevent clients from reusing stale or inappropriate data in response to further requests

Layered system - Service Chaining: A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. Intermediary servers may improve system scalability by enabling load balancing and by providing shared caches. They may also enforce security policies.

Uniform interface:

The uniform interface constraint is fundamental to the design of any REST service. The uniform interface simplifies and decouples the architecture, which enables each part to evolve independently. The four constraints for this uniform interface are:

  • Identification of resources

Individual resources are identified in requests, for example using URIs in web-based REST systems. The resources themselves are conceptually separate from the representations that are returned to the client. For example, the server may send data from its database as HTML, XML or JSON, none of which are the server’s internal representation, and it is the same one resource regardless.

  • Manipulation of resources through these representations

When a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource.

  • Self-descriptive messages

Each message includes enough information to describe how to process the message. For example, which parser to invoke may be specified by an Internet media type (previously known as a MIME type). Responses also explicitly indicate their cacheability.

  • Hypermedia as the engine of application state (HATEOAS)

Clients make state transitions only through actions that are dynamically identified within hypermedia by the server (e.g., by hyperlinks within hypertext). Except for simple fixed entry points to the application, a client does not assume that any particular action is available for any particular resources beyond those described in representations previously received from the server.

Headers

Each of the supported methods can be overridden if you set the X-http-method-override header. The Accept and Content-Type request headers are required for proper data formatting. These request headers have the following valid values:

  • Accept: application/json, application/xml
  • Content-Type: application/json, application/xml

Restful web services operations

  • GET : Read the resource content
  • PUT :Update/Replace
  • POST : Create the resource Content
  • PATCH : Update/Modify the resource
  • DELETE : Delete the resource Content

POST, PUT, and PATCH operations require you to provide both headers. The GET and DELETE operations require only the Accept header. Failing to provide the required headers results in a 400 Bad Request error

REST Response HTTP Status Codes

Status Code Message Details
200 Success Success with response body.
201 Created Success with response body.
204 Success Success with no response body.
400 Bad Request The request URI does not match the APIs in the system, or the operation failed for unknown reasons. Invalid headers can also cause this error.
401 Unauthorized The user is not authorized to use the API.
403 Forbidden The requested operation is not permitted for the user. This error can also be caused by ACL failures, or business rule or data policy constraints.
404 Not found The requested resource was not found. This can be caused by an ACL constraint or if the resource does not exist.
405 Method not allowed The HTTP action is not allowed for the requested REST API, or it is not supported by any API.

References

[1] REST API tutorials

[2] REST

Share: Twitter Facebook Google+ LinkedIn
comments powered by Disqus