When to use REST? What are some practical use cases of REST web services? How does it work? What's the “catch”, why has this new architecture for web services had such an impact on the industry? How is it any different/better than SOAP? Why use RESTful web services after all?
“Tormented” by all these questions related to the REST approach/alternative to building web services?
Relax now, you'll have your answers in a minute (or a few seconds)!
For here are the REST-related “enigmas” that I commit myself to solving in today's post:
- What is REST and how does it work?
- Which are the specific use cases for building web services using the REST architecture?
- What's driving it? Why is this technology increasingly popular?
- What sets REST apart from the traditional SOAP approach to web services?
- When NOT to use RESTful web services?
And now... the answers that I promised you:
What Is REST and How Does It Work?
Here are some valid answers to all your “What?” questions: “What is REST?”, “What are web services”, “What are RESTful web services?”
- REST is the native API of web browsers
- REST is how one creates web services
- web services are... the future of everything: creating and publishing APIs that would do CRUD (create, read, update and delete)
- … thus making machine-to-machine communication possible, making apps' functionality accessible to multiple users and external systems
- RESTful web services are those resources on the web that can be tapped into for retrieving certain information
“And how does it work?”
First of all, we should get one thing straight: REST is not an official standard! It's more of an architectural style, the one organizing a network of systems, where the “systems” are basically servers and clients.
Here's how it works:
Clients make a request to the web servers; the latter process it and, in response, return the appropriate web pages. And in this request-and-response equation, RESTful web services are the very resources on the web that servers tap into for retrieving the requested data.
Does this definition shed any light on your RESTful web services-related questions?
Why Use RESTful Web Services?
Here's the actual context where the RESTful web services technology emerged and “grew like a beanstalk”, with a huge impact on the industry:
The web “exploded” and, starting with web 2.0, the interaction between websites and client apps, between multiple sites, multiple devices, sites and databases, became increasingly intense. And more and more “demanding”, calling for a new technology that could handle and streamline this communication taking place on the web.
And here's where web services and REST, a new way of building them, emerged!
The REST architecture is designed to build:
- maintainable
- lightweight
- scalable
… web services, which make retrieving the data requested and “exposing” all that information far less cumbersome.
As compared to the conventional SOAP/XMLRPC web page-scrapping method.
Data's being passed on the web, from one website/app/device/database to another, faster than ever these days. Just think about all those websites incorporating Twitter and Facebook content!
Or of websites “capturing” data coming from multiple sources: financial information, sales data, online communities...
RESTful web services is the technology that streamlines all these intense data “harvesting” processes!
This is the answer to your “Why use RESTful web services?” question.
When Should You Use RESTful Web Services? 5 Practical Use Cases
There are specific use cases when you should go “the RESTful way”.
Adopt this approach to building web services if:
1. In your distributed app it's crucial to keep the coupling between client and server components to a minimum:
- you'll need to be able to update your server frequently, without having to update the client software, as well
- your server's going to be used by multiple clients, yet you don't want them to have control over it
Just make sure you follow all the REST constraints for achieving this kind of basic level of coupling. Maintaining a purely stateless connection will be challenging, but not impossible if you “follow the rules”.
2. It's a custom, on-demand digital product that you're developing
Such as an Ubercart or Drupal online store that you're putting together on a remote cloud server:
- you set it up
- create a suitable architecture that would scale the environment if/when this your custom product goes viral
3. You want your game's high scores and user community forums to be displayed both in-game and on the web
Let's say that you're a mobile/console game developer facing the above-mentioned “challenge”.
In your practical use case you can:
- have your Drupal site publish an API, using Services (thus doing “CRUD” with the data that needs to be “harvested”)
- leverage a RESTful type of communication with the Drupal site in order to retrieve that data and have it displayed in-game, on mobile/console, too
4. You want to create a user alert system on your e-commerce website
One that would alert your customers, via your e-commerce mobile app, whenever a product that they visualized becomes available (or its price drops).
Also, you want those alerts to pop up in an iPhone app and on Facebook, too.
And the solution is:
Your Drupal site (for yes, it's a Drupal site that you own in this scenario) will use Services & a custom module to have the example.com/alerts/uid API published. And it's this specific API that the iPhone app and Facebook will use for manipulating that particular content to be shown in the user “alerting” message.
5. You want to provide (paid) access to commercially-controlled data
Such as movies, music, stock or trading data.
Imagine that you own an event venue and you publish a ticketing API. People (such as ticket brokers) will be charged for gaining access to it.
In short: RESTful web services for can be used for all kinds of commercial activities, as well.
Just use them to create and to publish the API that will do CRUD with precisely that commercially-controlled data that people are willing to pay for gaining access to!
What Sets REST Apart from the Traditional SOAP Approach to Web Services?
Of simply put:
Why use RESTful web services instead of the traditional SOAP-based web services?
Here's a list of strong arguments:
- with REST, all that intense data interaction is more lightweight; it doesn't weight so heavy on your web server like a SOAP page-scrapping method would
- with REST, only the specifically requested information gets retrieved, instead of having whole web pages scrapped off the “target” content (like with the SOAP approach)
- the architecture is way simpler than the SOAP one and it leverages the standards (and protocols) of modern web
And what does this last argument even mean?
It means that heavy SOA (Service Oriented Architecture) is shifting to lightweight WOA (Web Oriented Architecture), since these days apps need to tap into a web that's “packed” with REST resources.
And so, instead of leveraging a few point SOA services, data gets collected and displayed via millions of granular REST resources. Developing arbitrary apps, that interact over the network, has become conveniently easier.
Complex things (systems) get simplified!
When not to Use REST Web Services?
There are — as I've just pointed out — use cases when the REST approach is the perfectly suitable one: business-to-consumer apps.
But there also are specific cases when RESTful web services don't work so well: B2B apps!
Take this practical example here:
A bookstore might find it a bit more challenging to make a volume purchase from an online vendor as compared to a regular customer.
It would need to “juggle with” several apps to track shipment, sales, determine re-orders etc. And where do you add that one app might need to be re-entered into other apps, turning the entire process into an overly complex, hard-to-manage one.
The END!
Have I managed to answer your “Why Use RESTful web services?” question or not quite? Or just partially?
Do be honest and, if it's the case, share your other REST inquiries and dilemmas with me! Or point out those use case examples or explanations presented here that you'd like me to shed some more light on.
