The World Wide Web may be regarded as a REST-based architecture. A RESTful architecture is built on the client-server paradigm, with stateless, cacheable communication between clients and servers. It’s important to note that REST is neither technology nor a standard but an architectural alternative to traditional RPC and SOAP. REST is a software architectural approach for creating distributed applications that can communicate via HTTP.
This article talks about REST, elements of its architecture, differences between SOAP and REST, constraints of REST architecture, and RESTful services.
Elements of the REST Paradigm
The key elements of the REST architectural paradigm are the following:
- Client – this is the consumer that sends a request for a resource to the server.
- Server – this is the producer that provides an API for accessing its data and operations.
- Resource – this is any content, i.e., a text file or an image that the server returns to the client as a response.
REST-based architectures are characterized by requests and responses for bidirectional communication between a client and a server. In this type of communication, the client requests resources from the server, which sends responses back to the client.
The REST Request Structure
A REST request comprises a URL, an HTTP method, request headers, and the request body optionally. The server sends back the status code, response headers, and a body to the client in return.
Here are the purposes of each of the elements of a REST request:
- HTTP method – this describes the operation to be performed with a resource.
- Endpoint – this comprises a Uniform Resource Identifier (URI) that can locate the resource. Uniform Resource Location (URL) is the most common type of URI and represents the complete web address.
- Headers – these are used to store metadata relevant to both the client and the server, such as name or IP address of the server, authentication, API key, and information about response format, etc.
- Body – this represents a piece of data sent along with the request to the server. You might want this piece of data to be used to add or edit data at the server.
What is the Difference Between SOAP and REST
SOAP and REST are two popular technologies to invoke web services. While SOAP is a protocol that defines a standard for communication between a server and a client using XML-based message exchange format, REST is an architectural style used to build lightweight services that can communicate over HTTP.
Unlike SOAP web services, RESTful web services are stateless. SOAP web services can communicate only using XML, but RESTful web services can work with JSON, XML, HTML, and even plain text. SOAP requires much more bandwidth than REST.
The following code snippet illustrates a typical SOAP request:
<?xml version = "1.0"?> <soap:Envelope> xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding"> <soap:body emp="http://localhost/customers"> <emp:GetCustomerById> <emp:CustomerId>1</emp:CustomerId> </emp:GetCustomerById> </soap:Body> </soap:Envelope>
The following URL shows how the same request can be represented in JSON:
http://localhost/payroll/EmployeeDetails/1
The REST Response Structure
Typically, in a REST-based architecture, servers, and clients communicate with each other using requests and responses. As clients demand resources from the server, the server, in turn, sends the response to the client.
The server sends a structured response to the client that comprises the representation of the resource, i.e., a description of the current state of the resource. This representation can be in different formats – the popular and widely used ones are JSON and XML. JSON is commonly used in REST-based architectures as it is less verbose and lightweight than XML. If needed, the server can also include hyperlinks or hypermedia that links to other resources.
The REST Architectural Constraints
The REST architectural paradigm defines a few best practices, also known as constraints, discussed below:
Client-Server
In a RESTful architecture, the server and the client are clearly isolated from each other. While the server doesn’t know the user interface, the client doesn’t know the application’s business logic or how the application persists data. You can change the server and the client independent of one another.
Stateless
The foundation of REST architecture is the stateless HTTP protocol. In a REST-based architecture, clients and servers should communicate with each other in a stateless way. Most importantly, state information can only be managed at the client, not at the server. In other words, each request is isolated and disconnected in REST architecture, and no client information is preserved between requests.
Cacheable
Caching is a proven technique that can enhance the scalability and performance of an application. A RESTful architecture should allow the clients to cache data. For managing cache efficiently, the architecture should enable you to decide whether to use response caching.
Code on Demand
In a typical REST architecture, a server sends back static representations of resources. This response is usually sent in the form of JSON or XML. However, if needed, a server can send executable code as well.
Uniform Interface
REST provides a standard, uniform interface that is fundamental to the design of a RESTful service. This interface between a client and a server restricts the operations that can be performed on the server using standard HTTP verbs that include GET, POST, PUT and DELETE.
Layered System
The REST architectural style enables building an architecture composed of multiple layers of servers where you deploy the API on one server and store data on another.
What is a RESTful Service?
A RESTful Web Service or a RESTful Service or a RESTful API is a platform and language independent service that adheres to REST-based architecture constraints. It comprises a collection of resources that contain a basic URI for accessing the service, a MIME type (i.e., JSON or XML), and a set of pre-defined actions such as HTTP GET, HTTP POST, HTTP PUT, HTTP PATCH or HTTP DELETE). However, unlike web services, there is no standard defined for RESTful services. REST is an architectural style – not a set of standards.
Figure 1 below illustrates how a RESTful API interacts with clients or consumers to perform read, add and edit operations against a database.
The following are the supported data formats in a RESTful API:
- application/json
- application/xml
- multipart/form-data
- application/x-wbe+xml
- application/x-www-form-urlencoded
Resources in REST-based Architectures
REST is an architectural paradigm used to describe how data is displayed, accessed, and changed over the Web. RESTful web services are stateless because of the stateless nature of the HTTP protocol on which these services are typically executed. RESTful web services perform CRUD operations using the stateless HTTP protocol and the HTTP operations such as GET, PUT, POST, and DELETE. REST is adept at doing anything that SOAP and XML-RPC can accomplish.
A resource is the most crucial concept in REST, and it is identified using unique URIs. Resources are represented in digital format such as HTML, XML, JSON, RSS, etc. Typically, resources represent state and functionality in a REST-based architecture and are identified using logical Uniform Resource Locators (URLs). You can read a previous article to know more on resources and resource-oriented architectures.
Summary of REST and REST Services
The REST architectural paradigm was coined by Dr. Roy Fielding in his 2000 doctorate dissertation. It has quickly become popular worldwide in building and architecting applications that connect via HTTP. It received broad acceptance worldwide instead of SOAP and WSDL-based Internet services thanks to their simplicity. RESTful web services have become widely popular primarily because of its support for enhanced scalability and performance.
