There have been a
handful of approaches and technologies for accomplishing
application-to-application communication. On the Microsoft stack itself, you
had COM/DCOM, .NET remoting, ASMX Web Services and WCF Services, just to
mention a few that I know. Other platforms supported countless technologies
that tried to communicate across machine, network and platform boundaries.
Standards start evolving naturally when the number of choices gets beyond a
point of imagination. That's how web services started flourishing as an
industry standard for app-to-app communication and provided the much needed
platform interoperability
Every name worthy
technology supported web services that
are based on SOAP or WSDL . In particular, SOAP based web services wrapped the
business engines of complex enterprise LOB
applications. Any other app that wants to communicate with the enterprise app
must know how to deal with the SOAP web service, means the client environment
needs to support SOAP toolkit
Web like Communication
When everybody
thought SOA and SOAP web services are here to stay, the industry started
shifting in a direction that leveraged the good old HTTP protocol . That is,
design your services in the same way web or internet is architected. HTTP is
the basic protocol of web. SOAP web services use HTTP protocol, but they are
not architected in the way web is architected.
The concept of web
is quite simple and intuitive. All that you need to know is the URL (URL is
just one part of the URI that uniquely identifies a web resource). If you just
know the URL, it's enough and your browser will take care of the rest.
Technically it means that your browser has invoked any one of the HTTP's basic
methods like 'GET' or 'POST' or 'PUT' or 'DELETE' on the unique web resource,
for example 'index.php' of https://facebook.com
Now apply the same
principle to your service. Your service is given the URI and the operation to
be performed on the URI. Your service executes and sends back the response.
Your service is now called "RESTful".
In simple terms, web style architecture enabled user-to-app
communication through browser. With RESTful services, the same web style
architecture enables app-to-app
communication but without browser
REST and Real Life
There are many
advantages with REST style. One thing that stands out, in my opinion, is the
creation of uniquely identifiable resources. URIs were traditionally seen as
pure web resources like index.html, home.aspx, homepage.php, MyPhoto.jpeg or
Something.xml. These are physical files living in the drives of web servers.
REST is resource oriented and shows the resources in different dimensions. The
URIs are no more pointers to physical files on a web server, they can be
anything and everything. An URI shall be a pointer to a real world object like
a customer, a PO, list of products manufactured by a company, a linked-in or
facebook profile or my Maruti Swift (Vehicle Identification Number, VIN)
If the client needs
the details of my car, all that needs to do is to send the URI that uniquely
identifies my car.
Right way to think
about this is, if the client is an app then it receives the details of the car
in the format wanted by the app. It's for the app to do whatever it wants to
do. If a browser sends this URI then you get to see the details of the car in the
browser window. Hence for every identifiable resource there is a web UI
(obviously it's dynamic) and a web API.
RESTful services
force people to coin URIs for every object worth identifying. There could be
billions of URIs, transferred between people and apps.
You want to suggest
me a book, all that you will do is send me an Amazon URI that uniquely
identifies the book.
You want to
recommend me a person's profile, you will send me a Linked-in URI that uniquely
identifies the person.
In future there may
be QR codes that will just contain the URIs displayed on shop bill board or in
an advertisement hoarding. You will use your mobile, scan the QR code, gets the
URI and the 'REST' is obvious. Like this there are many different business cases.
But the key lies in
creating a URI for every object that deserves to be identified. Once done there
are unlimited possibilities. This is where REST scores better than other web
services by leveraging the WEB architecture
No comments:
Post a Comment