We sometimes get questions about REST. “What is it exactly?” “How does it work?”. In its long form, “Representational State Transfer” doesn’t make it easier to understand. Nor do the words usually associated with it, such as in “Should I have a REST API?” or “Should I have RESTful Services?”. And, if we give a basic definition like “REST is an architectural style for the design of Web services”, that kind of leaves you hanging as well. So, in this post, we’ll do our best to put the concepts in an order that will help you understand.
Web services is a good place to start.
First, Web Services
A Web service is a means by which two applications can talk to each other over the web. It is a framework for their conversations. Often, these conversations are going on without human interaction. They do need to be carefully set up by a developer, however.
Good reasons to use Web Services
So why would applications be talking to each other over the web without human interaction? Interoperability with a minimum of human intervention. Web services exist mainly to get things to work together smoothly on the web, no matter what kind of platform, software, architecture etc. is involved. For example, your company might be using a web service to help its old (legacy) finance software communicate its information to a more modern application at the head office. Perhaps another web service enables mobile users to work in the system even if it wasn’t built with mobile users in mind. Another example: your customer order system needs to pull information from the shipping company it uses, to establish the cost of each shipment in real time and present it to the customer on a web page so the customer can agree to it.
Another good reason: Web Services can help save on development time
Web services are also very helpful for developers: Instead of building an application from scratch, the developer can have his application call upon web services for certain tasks. This can save your company a lot of development time and a lot of money.
How Web Services Operate
The way two applications talk to each other in a Web service can be compared to when you are using your web browser. You type something into your web browser (let’s say it’s Google Chrome) and it responds by searching for and presenting results to your request. This is a client-server situation. Your computer is the client and Google is the server.
Web services also need to work in a client-server relationship. The application playing the role of the client sends a request, the server application processes the request and sends back information. In the case of web services, the information usually isn’t human-readable. It’s data. The client application then feeds the data it has received into another application or acts upon it directly, depending on what is required at its end.
Communication Protocols
Of course, two applications having a conversation over the web might differ greatly from each other. They might be running in very different environments, too. The client might be an Apple iPad with an Apple operating system and the server might be an Oracle Cloud server running a Program using language that your iPad has never even heard of. This is why rules had to be created for web service communications.
When web services started getting popular, back in the early 2000s, protocols were established to make their set up and operation easier. The better-known ones were SOAP (Simple Object Access Protocol) XML RPC (Extensible Markup Language-Remote Procedure Call) and JSON-RPC (JavaScript Object Notation-Remote Procedure Call).
REST, although it appeared roughly at the same time for the same reasons, is often compared to these protocols. But, it’s different. As stated above, it is an architectural style.
REST
REST gradually became the most popular way to manage web services because of its flexibility. For example, SOAP requires the use of XML language, and JSON-RPC requires the use of JSON. REST can allow XML, JSON, HTML, Plain text and more. It is more flexible, and consequently, a more natural fit for Web developers.
What’s more, a RESTful service follows universally accepted methods when taking actions on the web (in the HTTP protocol). POST to create data, GET to retrieve, PUT to edit, and DELETE.
For a detailed technical explanation of REST’s properties, have a look at this excellent blog post by Kenneth Lange. If you want to find out more on how REST came about, look up this dissertation by Roy Fielding, it’s inventor.
So, back to REpresentational State Transfer. In the client-server relationship mentioned earlier, there is a transfer of server data in its representational State, meaning whatever state the resource requested by the client is represented in. The resource, a type of data (example: a customer’s account information) is identified by a URL. Its representational state can vary, depending on the language used.
API
You’ll notice I haven’t even mentioned APIs yet. The reason for this is that the two expressions are often run together without being explained separately.
API stands for Application Program Interface. This is a set of tools to build applications. There are APIs for Operating Systems, Databases and software libraries. None of these are necessarily on the Web. However, the APIs that we are talking about here, are for the Web. To take advantage of a web service, the developer needs to familiarize himself with its API. The Web Service API includes the communication protocol, chosen format, the description of how to perform actions or get data from the remote computer, libraries for the development language used and any other instructions or information the developer needs to get the web service operational for his needs. When a developer chooses a web service to use, he must immediately familiarize himself with its API.
RESTful API
A RESTful API gives the developer more flexibility in choosing the language used for the Server’s response. It also ensures that everything needed for the communication between the client and server is included in the communication itself. This way, the communication doesn’t depend on any other outside source to be complete. It, therefore, lowers the risk of failure. REST APIs also enable you to more easily scale your request.
More flexibility, more reliability, more simplicity and scalability make REST the preferred method of setting up a web service.
Conclusion
So, does your business need RESTful Services? You first need to answer the question “what Web services do I need” or “what Web services do I need to build?”. Of course, using RESTful APIs is the best way to build them.
Insum are application development experts. We can build custom applications for you. Interested? Contact us!
