What are RESTful Web Services?
Apr 15, 2013
Table of contents:
“REST” is a common word in the world of web applications and services. REST usually refers to the transfer of data between servers and clients. For example, if you wanted to get updates from Twitter, you would be using Twitter’s REST API.
In this post I hope to explain exactly what REST means, how you can use it to get data from web services and how you can build your web applications to take advantage of RESTful architecture.
What is REST?
Representational State Transfer (REST) is a type of distributed software architecture that is predominately used on the Internet. REST basically controls how data is sent to and from servers and clients and acts as a set of rules that govern this type of data transfer.
REST follows many of the same conventions as Hypertext Transfer Protocol (HTTP), making it easy to pick up and understand.
When using REST, you will usually want to do one of the following four actions:
- Create (POST)
- Retrieve (GET)
- Update (PUT)
- Delete (DELETE)
POST, GET, PUT and DELETE are HTTP request methods. By making each of the methods represented by a verb, the methods are easy to understand and remember.
This all might seem complicated, but you’ve already been using all of these methods whilst browsing the web. The two most common and visible HTTP methods are POST and GET.
When you submit data through a form on a website, you are making a POST request. A POST request is simply a message to the server that has the submitted data within the body.
It’s easy to spot a GET request because it is often visible in the URL of the website. For example, https://www.youtube.com/watch?v=9bZkp7q19f0 is using a GET request. In this example, your browser is using a GET request to get the video that is represented by 9bZkp7q19f0.
REST URIs
An important part of RESTful architecture is the URIs that are used to transfer data. REST URIs are structured to ensure that they are intuitively understandable and obvious as to their purpose.
For example, to get all the users of a particular service, the REST URI would usually look like this:
domain.com/users
This would return all of the users of the system.
To get the details of a particular user, the REST URI could be:
domain.com/users/1
As you can see, the purpose of these URIs is extremely obvious and follows in the intuitive nature of RESTful architecture.
JSON, XML or both
When you make a REST request, you are returned a representation of the data from the server. The data you are returned is not the actual database, but rather data in a format such as XML, JSON or both.
XML (Extensible Markup Language) is a markup language that is used to store and transfer data. JSON (Javascript Object Notation), despite it’s name, is a language agnostic method for serialising and transferring data.
When transferring data you can use either XML or JSON. Often web services will offer both formats. There are many differences between the two formats and so it’s hard to say whether one is better than the other. XML is a markup language and is used for transferring different types with great flexibility. JSON is generally lighter than XML and so the same amount of data can be transferred with less bandwidth. JSON also fits nicely with Javascript heavy web applications.
The choice between XML or JSON really comes down to your application. Whilst JSON is perfect for lightweight data transfer in web applications, it does have restrictions and constraints that XML does not.
REST Vs SOAP
SOAP (Simple Object Access Protocol) is a protocol for transferring data across networks. SOAP relies on XML and is generally considered much more complicated than REST.
REST is simpler than SOAP because it is based on GET, POST, PUT and DELETE. SOAP on the other hand has it’s own methods for accomplishing the same things. This means you inherently already know how to use REST, whereas SOAP requires a level of learning.
REST is also generally considered better than SOAP because it allows for JSON. As I mentioned earlier, this is particularly important for consumer web services that rely on Javascript heavy web applications and require a much simpler and lighter method for data transfer.
SOAP is older than REST and comes burdened with specifications for it’s use. REST has no specifications and so once again, it makes it easier to use.
SOAP does have some specific advantages over REST. For example, REST only allows for SSL as a method for security, whereas SOAP has security features like WS-Security, although you wouldn’t need it for the average application.
REST is seen as the future of web applications because it is hard to find a case where SOAP is actually a better choice. REST is easier, simpler and has become the chosen method for companies like Google Facebook and Twitter. REST forms an integral part of Ruby on Rails and allows for easy integration with Ajax heavy asynchronous applications.
Conclusion
So to conclude, REST is a type of data transfer that is built upon the architecture of the HTTP protocol. It allows you to easily send and retrieve data between two different services using XML or JSON.
When structuring your web applications, it’s usually good practice to build them using RESTful architecture. This means that collections and resources are easily recognised and can form the basis of building a RESTful API.
When you build an application that requires a Javascript heavy front-end, or integration with a smartphone application, using a RESTful architecture becomes a necessity because it allows you to transfer data from the API to the client. It’s often good practice to plan out your RESTful collections and resources at the very outset.
So the next time you start a web application project, think about how you can make it more RESTful. It will probably not only make your application’s architecture better, but it will also allow you to easily build an API in the future to integrate with other services or applications.
