Whether you're new to the REST game or a seasoned vet, sometimes it's helpful to remind ourselves as to what exactly makes a set of services 'RESTful'.
Join the DZone community and get the full member experience.Join For Free
Recently, one of the most advocated means of creating services has been through the use of RESTful services. Before we continue, we would like to explain exactly what REST means and what criteria must be met before a service is indeed RESTful.
REST was a word coined by Roy Fielding in his Ph.D. thesis meaning Representational State Transfer. It is an architectural design that relies heavily on the use of hypermedia to transmit information from one system to another. Its whole engine is based on the concept of Hypermedia As The Engine of Application State (HATEOAS). So, what constraints make a service a fully RESTful service? Some of the key constraints we would be looking at include:
- Uniform Interface
- Layered System
- Code on Demand
A service is indeed RESTful if there is a separation between the client presenting the view and the server computing the logic of the application. A service is indeed RESTful provided a separation of concerns exists between the layer of the client and the server. The relationship of the client and server is such that the client and server can exist independently, communicating only through hypermedia calls and implementation. This feature makes RESTful services fundamental in today’s world where the division of labor between the client and server is becoming more obvious and fundamental.
A request between a client and server must always contain all the information needed to understand the communication. Managing the state of a request has no business on the server and can only be stored on the client if need be. The server does not keep certain information about an ongoing transaction except for what is passed from the client to the server and nothing more. It has its advantages and disadvantages. The advantage in that the server is reliable in that whatever is sent to the server produces a certain type of information. Scalability is also enhanced in that the server does not store any extra information. However, the disadvantage is such that repeated information is communicated to the server every time similar information is needed.
A cache is temporary memory storage. RESTful services afford the opportunity to make some services cacheable in the client memory so that fewer calls are made to the server, as the stateless nature of the service ensures that a lot of data is communicated between the client and server. However, this becomes an issue when data becomes stale and such information is still returned to the client.
Information is communicated in a standardized and uniform manner. The mode of action expected from a server by a client is usually defined in a uniform mode, and as such, different applications cannot define extra action types to the server. Such action types, like getting information from the server, updating information, and creating or deleting information on the server, are done uniformly.
This allows the RESTful services to be composed of different layers where the different layers act more like independent sections in the transmission of data from the client to the server and vice versa. Different layers can, in turn, see different forms of data and can work directly on that piece of information only. This allows for speed in some cases, but sometimes can be a cause for latency.
Code on Demand
The code to execute a certain action is only available when you ask for it. As such, this makes a service really lightweight, in that only the code that is needed is used and nothing more. A function to create a certain user is only made available when a request to create a user is made.
These are some of the constraints any service that claims to be a RESTful service must always obey.
Published at DZone with permission of Abdul Azeez Idris, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.