Representational state transfer (REST) is a software architectural style that defines a set of constraints to be used for creating Web services. Web services that conform to the REST architectural style, called RESTful Web services (RWS), provide interoperability between computer systems on the Internet. RESTful Web services allow the requesting systems to access and manipulate textual representations of Web resources by using a uniform and predefined set of stateless operations.
By using a stateless protocol and standard operations, RESTful systems aim for fast performance, reliability, and the ability to grow by reusing components that can be managed and updated without affecting the system as a whole, even while it is running.
REST defines 6 architectural constraints that make any web service – a truly RESTful API.
1. Client-server architecture
The principle behind the client-server constraints is the separation of concerns. Separating the user interface concerns from the data storage concerns improves the portability of the user interfaces across multiple platforms. It also improves scalability by simplifying the server components. Perhaps most significant to the Web, however, is that the separation allows the components to evolve independently, thus supporting the Internet-scale requirement of multiple organizational domains.
2. Statelessness
The client-server communication is constrained by no client context being stored on the server between requests. Each request from any client contains all the information necessary to service the request, and the session state is held in the client. The session state can be transferred by the server to another service such as a database to maintain a persistent state for a period and allow authentication. The client begins sending requests when it is ready to make the transition to a new state. While one or more requests are outstanding, the client is considered to be in transition. The representation of each application state contains links that can be used the next time the client chooses to initiate a new state-transition.
3. Cacheability
As on the World Wide Web, clients and intermediaries can cache responses. Responses must therefore, implicitly or explicitly, define themselves as cacheable or not to prevent clients from getting stale or inappropriate data in response to further requests. Well-managed caching partially or completely eliminates some client-server interactions, further improving scalability and performance.
4. Layered system
A client cannot ordinarily tell whether it is connected directly to the end server, or to an intermediary along the way. This means that the client doesn’t know if it’s talking with an intermediate or the actual server. So if a proxy or load balancer is placed between the client and server, it wouldn’t affect their communications and there wouldn’t be necessities to update the client or server code. Intermediary servers can improve system scalability by enabling load balancing and by providing shared caches. Also, security can be added as a layer on top of the web services, and then clearly separate business logic from security logic.[12] By adding security as a separate layer enforces security policies. Finally, it also means that a server can call multiple other servers to generate a response to the client.
5. Code on demand (optional)
Servers can temporarily extend or customize the functionality of a client by transferring executable code: for example, compiled components such as Java applets, or client-side scripts such as JavaScript.
6. Uniform Interface
The uniform interface defines communication between clients and servers. Once a developer becomes familiar with one of your APIs, he should be able to follow a similar approach for other APIs.
In REST, information on the server-side is considered a resource, which developers can access in a uniform way using web URIs (Uniform Resource Identifiers) and HTTP. Because REST uses HTTP as the communication protocol, the REST style is constrained to a stateless client/server architecture. The GET, POST, PUT and DELETE methods are typically used in REST-based architectures. The following table gives an explanation of these methods:
REST allows requesting clients to access and manipulate web resources by using a uniform and predefined set of rules. Interaction in REST-based systems happens through the Internet’s Hypertext Transfer Protocol (HTTP). A Restful system consists of:
