15 December 2017
REST(Representational State Transfer) is a simple scalable stateless architecture used in enterprise web applications that runs over HTTPS.
Restful web service has following constraints.
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.
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:
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.
When a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource.
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.
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.
Each of the supported methods can be overridden if you set the
X-http-method-override header. The
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
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
|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.|