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 few key constraints we would be looking at include the following:
- 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 concern 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 our 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 at all time when 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 that the RESTful services are 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 only that piece of information. This allows for speed in some case 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 code 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.
Whether you are new to Linux or have experience, downloading this cheat sheet can assist you when encountering tasks you haven’t done lately.
Join the Red Hat Developer Program (it’s free) and get access to related cheat sheets, books, and product downloads.