You may have heard the term REST used regarding the development of web-based applications. REST APIs are also known as REST web services. They promise a simple way to use the existing protocols of the Internet in providing communication between applications and devices. Before we look at the basics of how to use REST APIs, let’s take a step back and look at a more basic question.
Table of Contents
What is REST?
So, what is REST? REST is an acronym that stands for Representational State Transfer. It is an architectural style that is used for creating networked applications such as those we use daily on the Internet. Applications that make use of this architecture are known as RESTful applications.
One of the reasons that REST technology is a favored method of developing networked applications is that it takes advantage of the underlying structure that exists on the Internet. According to Dr. M Elkstein, REST uses the simple HTTP protocol that is used by the Internet rather than employing more complex methods such as COBRA or RPC. As the Web itself is based on HTTP, it can be seen as a system designed with a REST-based architecture.
REST considers all objects, documents, or other things that can be sent to another service or stored to be a resource. RESTful systems are stateless, meaning that there is no need for any historical information to be saved or conveyed to complete a request. All pertinent information a server may need to complete a request must be part of the request itself. The REST architecture also allows the separation of clients and servers. Since they all will communicate with the same basic language, they can evolve in other ways without impacting their connectivity.
For an application to conform to the RESTful architectural style it needs to work within the boundaries of six constraints. These were originally described by Roy Fielding in his doctoral dissertation that defines the RESTful style. According to restapitutorial.com, these are the constraints and their reasons for being part of the REST architectural paradigm.
6 Constraints of the REST Architectural Style
-
Uniform Interface – This constraint allows for the decoupling of clients and servers, allowing independent evolution without impacting connectivity. It includes 4 guiding principles that an application must adhere to in order to be RESTful. It must be resource-based and allow the manipulation of resources through representations of those resources. Messages sent need to be self-descriptive which means the message itself must contain enough information to allow it to be processed. It also employs the concept of using hypermedia as the engine of an application’s state. This has to do with passing links in returned messages to enact the retrieval of objects.
-
Statelessness – The word state is part of the REST acronym, which implies it has an important role in the architecture. What this means is that the state required to fulfill a request is contained in the request’s parameters, body, or headers. This statelessness enables scalability since the server does not need to maintain, update, or communicate that session state. It also allows for easier load balancing since session affinity is not an issue.
-
Cacheable – In order to improve network efficiency, data within a response to a request must be designated as cacheable or not cacheable. This allows for a more efficient transfer of data, as cacheable requested data can be reused, eliminating the need for it to be resent. Caution must be taken in cases where the cached data could potentially have changed considerably since the initial request.
-
Client-Server Separation – This constraint is related to the uniform interface requirement. The separation means that client need not be concerned with data storage and servers do not need to be concerned with the user state or interface of clients. This allows for a more flexible system that can accommodate the easy replacement of servers and clients as long as they do not change the interface.
-
Layered System – Clients do not need to know whether they are connected to the actual server they are interrogating or an intermediary machine. This enables security policies to be enforced by intermediaries as well as for processes such as load balancing and cache sharing to be enacted.
-
Code on Demand – This is an optional constraint by which servers can customize the functionality of a client temporarily by transferring code that it can execute locally. Examples are Java applets and JavaScript.
These constraints are meant to ensure that by their compliance, any kind of distributed system or web service can have similar properties of performance, scalability, portability, and reliability. Any violation of the first 5 constraints eliminates the possibility of referring to the application as being RESTful.
Advantages and Disadvantages of REST
As with any programming or development paradigm, there are always some tradeoffs. The major benefits of working within the constraints of REST APIs are:
-
Use of the Hypertext Transfer Protocol (HTTP). This protocol is familiar to users of the Internet, and lends itself to simplified message handling. All REST-based applications communicate status via standard HTTP status codes, such as 404 to indicate a resource that was not found or 500 to show there was an unrecoverable application failure.
-
Simplified security and encryption are an advantage of RESTful systems, as again, the underlying frameworks already in place on the Internet are utilized. Secure Sockets Layer (SSL) and Transport Layer Security eliminate the need for additional technologies that introduce unnecessary complexity.
-
REST is language-independent. If a programming language can make web-based requests using HTTP, it can be used to develop REST web services.
Potential disadvantages of the REST architecture include:
-
The inability of HTTP to send push notifications to clients. Client-side polling needs to be used if a service intends to be able to update clients.
-
The stateless nature of RESTful services means that state management tasks must be performed on the client side.
-
REST does not have a definitive standard, which can cause some controversy over whether a design is truly RESTful or not.
Conclusion
REST offers a simplified approach to building web-based services. It has a number of advantages as well as some concerns when used in certain situations. It is definitely worth looking at if you are developing web services.
