Nuts & Bolts Of RESTful Web Services
The most basic definition of the term RESTful web services comes from within i.e. anything available on the web is a web service. But technically, they are a piece of software that follows some XML encoding standards. Most people tend to confuse web services with APIs, but the general flow should go this way –
All web services are APIs but not all APIs are web services.
This statement is based on the general flow which entails that API is anything that allows two applications to communicate whereas for a web service these applications are web-based communicating over HTTP.
Web services can be broadly classified into three major categories –
a.) SOAP (Simple Object Access Protocol) – It is a protocol that uses XML based messages for communication. It comprises of three parts, an envelope which describes the message and how to process that, encoding rules and a convention for representing remote procedure calls and responses. This was very widely used in the past, but this has lost its spark nowadays. As the envelope part in this makes it very heavy and processing heavy. This transition is following the emergence of mobile-based devices with limited computational capabilities.
b.) XML-RPC (Remote Procedure Calls) – This allows calling procedures on a remote machine over HTTP. This communication is very fast and is very simple, though this can be used only in specific use cases, as one needs to know about the function on the remote machine to use this, hence these are not preferred.
c.) REST (Representational State Transfer) – RESTful web service is more of an architectural style which encourages to develop loosely coupled applications over HTTP. The data exchange can happen via XML, JSON, plain-text, and HTML. Let’s discuss more on why this is so widely used.
RESTful Web Services Overview
When we consider REST under this everything is classified either as a Resource or as a Collections.
A Resource in REST is an object having a type, has some information associated with itself and has relationships with other resources. It is similar to Object Instance in Object-Oriented Programming. Unlike Object, it can be accessed via a few predefined methods only over HTTP (GET, POST, PATCH, PUT & DELETE). A collection is a group of similar resources. Resources can exist as a single unit as well called as Singleton Resource.
Using the above terminologies as a base, RESTful web services is an Architectural Style it works on six basic constraints which encourage design on loosely coupled application –
a.) Uniform Interface – This ensures that all the resources are accessible via a consistent interface makes it easy to understand things. Hence all the resources can be accessed in the same way as the GET method. For eg. if we want to get all the players from a team we can create an interface like ‘/players’ and we can do an HTTP GET on this. If we want to get only one player from this, we can do that via ‘/players/[id]’. Similarly, for updating one we can do a PUT call with id.
b.) Stateless – By this, we ensure that there is no presumptuous approach while handling an API call via a RESTful web interface. A REST API would always give consistent results for the same interface, it would not take/assume state based on any previous call that has been made.
c.) Fast – All the REST APIs should have the capability to cache requests-responses for faster handling of calls. This comes in very handy whenever a common set of data is required by all the clients from the server.
d.) Language and Platform Independent – This entails that the REST APIs can be coded in any language be it JAVA REST API, Python, C++, etc. Since this is just an architectural style, we can code RESTful web services APIs in the language of our choice.
e.) Client-Server – By this, the client becomes independent of the server, it just needs to know the interface of the server to interface with the server and the Client can evolve independently of the server.
f.) Different Data Formats – REST web APIs can communicate via any kind of data format be it JSON, XML, plain text or even HTML. But people mostly prefer either to communicate via JSON or XML.
RESTful web services concepts
Verbs
We have already discussed that resources are the fundamental concept in RESTful web services and REST API and that each resource has its own unique URL. Methods can be executed on resources via their URL. The table below lists the standard methods that have a well-defined meaning for all resources and collections.
Generally, there are two ways we can find which methods accepted by the resource or collection. Not required to implement all the methods to all resources and collections.
Call OPTIONS Method for the URL and check the “Allow” header in the response. There you will see all methods supported by resource or collection in the comma-separated list.
Just call the URL with the method and check the response with the “405 Method Not Allowed” response if the method is not supported for the resource or collection.
HTTP Status
Below are the methods with status codes should we follow the REST standards –
There are dozens of status codes, but don’t worry—you don’t need to know them all off the top of your head. HTTP status codes are divided into classes grouped by the first digit of the number. The available classes are:
- 1xx – Informational responses
- 2xx – Success
- 3xx – Redirection
- 4xx – Client errors
- 5xx – Server errors
Richardson Maturity Model
Leonard Richardson developed models which are the Richardson Maturity Model (RMM) that helps us to organize our REST APIs. The RMM is a way to grade your API according to the constraints of RESTful web services. The better our REST web API adheres to these constraints, the higher its score is.
This RMM should be used at the time of designing the REST API to make sure the web services are fully RESTful.
In this model, we have 4 levels numbered from 0 to 3. Level 0 is not RESTful, Level 1 is the starting of REST and Level 4 means our web API is fully RESTful.
Level 0: The Swamp of POX
- These services have a single URI and use a single HTTP method (typically POST). These are the most primitive way of building service-oriented architecture applications with a single POST method and using XML to communicate between services.
- The Swamp of POX (Plain Old XML) means that you’re using HTTP. Technically, REST APIs can be given over any application layer convention as long as they fit in with specific properties. In practice, everyone uses HTTP.
- Web API designed at this level are not at all Rest APIs and this is where SOAP-based web services take place. For example, Every request will be POST requests, so if someone wants to delete a player record they will have to send the action also in the request.
LEVEL 1: Resource BASED ADDRESS/URI
1) Every resource has its own URI at this level. This level utilizes multiple URI where each URL is an entry point to a particular resource. Still, this level uses only one method POST for operation. This is a beginning level for a REST API. In this Level, the Concept of Resource-based Address is presented, which lets you know there should be Individual URI for every Resource on the server (not at all like LEVEL 0 where we have a single URI for every incoming request from Client).
2) It’s like reducing the burden from the single endpoint (LEVEL 0 endPoint which handles all operations) into multiple Resource-Based URIs like Divide and Conquer algorithm.
3) If we just designed Resource-based URI and nothing else, then we are at LEVEL 1 of the maturity model.
In this level, the HTTP is simply utilized as a tunnel among client and server and we have not utilized the potential of HTTP as an Application Layer Protocol.
LEVEL 2: Utilize Potential of HTTP as Application Layer Protocol
1) These services have multiple URI and use multiple HTTP methods. RESTful web services API created at this LEVEL uses Standard HTTP methods/verbs and different HTTP status codes to do various operations on Resource URI. Along these lines, the Request Body will never again convey Operation data at this information. Hence, this API is much more mature than the API created at LEVEL 0 furthermore, LEVEL 1
2) This level indicates that your web API should use the protocol properties to deal with scalability and failures. Should not use a single POST method for all, but make use of GET when you are requesting resources, and use the DELETE method when you want to delete a resource.
3) Use the response codes of your application protocol. Should not use the 200 (OK) code when something went wrong for the request. By doing this for the HTTP application protocol, or any other application protocol you like to use, you have reached level 2.
4) This level is the good use-case of REST APIs, which advocate using different verbs based on the HTTP request methods and the system can have multiple resources.
LEVEL 3: Use Hypermedia or HATEOAS
1) If an API comes under this level means will be known as fully RESTful.
2) There are two parts to this: first content negotiation and another is HATEOAS. Content negotiation means different representations of a particular resource, and HATEOAS is about the discoverability of actions on a resource.
3) This level suggests using the concept of HATEOAS in APIs. The API response should contain the logical links of all the resources related to the current resource.
REST (REpresentational State Transfer) is used to build web services that are lightweight, maintainable, and scalable. More and more applications are moving to the Restful architecture. This is because there are a lot of people now using mobile devices and a wider variety of applications moving to the cloud.
The main aspects of REST are the resources that reside on the server and the verbs of GET, POST, PUT and DELETE, which can be used to work with these resources.
Systango, one of the prime product engineering and development companies in the UK have created a number of applications on the REST framework. Do you want to create your next web application on REST architecture or on any other such viral technology? Let’s schedule a call.
We are here to hear you.
