
We’re excited to hear your project.
Let’s collaborate!
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:
And now... the answers that I promised you:
Here are some valid answers to all your “What?” questions: “What is REST?”, “What are web services”, “What are RESTful web services?”
“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?
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:
… 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.
There are specific use cases when you should go “the RESTful way”.
Adopt this approach to building web services if:
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”.
Such as an Ubercart or Drupal online store that you're putting together on a remote cloud server:
Let's say that you're a mobile/console game developer facing the above-mentioned “challenge”.
In your practical use case you can:
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.
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!
Of simply put:
Why use RESTful web services instead of the traditional SOAP-based web services?
Here's a list of strong arguments:
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!
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.
We’re excited to hear your project.
Let’s collaborate!