Should The Web REST Its Case?

Today the Web is being treated as an application and messaging platform, as a publishing platform and as a medium. However, the initial intent and hence the design of Web was to host documents and make them available to everyone. Here is an excerpt from the summary of World Wide Web by Tim Berners-Lee:

The WWW world consists of documents, and links. Indexes are special documents which, rather than being read, may be searched. The result of such a search is another (“virtual”) document containing links to the documents found. A simple protocol (“HTTP”) is used to allow a browser program to request a keyword search by a remote information server.

The web contains documents in many formats. Those documents which are hypertext, (real or virtual) contain links to other documents, or places within documents. All documents, whether real, virtual or indexes, look similar to the reader and are contained within the same addressing scheme.

In a nutshell, the Web was intended for documents so that information can be shared. The design of the Web and underlying techniques like the HyperText Transmission Protocol (HTTP) and HTML target these hyperlinked documents and exclude the modern connotations.

Protocols

SOAP and XML-RPC

To be able to do more with the Web, a layer of abstraction was introduced. This layer introduced new protocols and data structure formats and new rules to abide by. XML-RPC is a product of this attempt and later evolved into SOAP to handle enterprise scenarios. Lets club both of them together for our purpose. The purpose of these protocols was to ensure communication between disparate machines with disparate platforms with disparate programming environments. That they did to the fullest extent. The utilities were offered as services, which the clients could use by requesting using the protocols. SOAP has now evolved to get more and more inclusive and stricter and tedious. A lot of specifications were developed which caused the effort and the cost of being able to use a service to climb up.

There are two problems with SOAP. One was that as Web was being used for all kinds of things, a lot of which were not enterprise or corporate. SOAP started getting oversized and bulky for them. Secondly, SOAP uses POST method of HTTP. (HTTP provides two commonly used methods – GET and POST. GET lets you retrieve information and provides a Uniform Resource Identifier (URI) for that. This URI can be used as an identifier for that information or resource. For using POST, a package has to be sent to the web server, a simple URI does not work.) Using POST meant SOAP had to do away with the URI and the associated basic benefits of simplicity, convenience and caching.

REST

So came in a new perspective REST – Representational State Transfer. REST, coined by Roy Fielding in Architectural Styles and the Design of Networkd-based Software Architectures takes an approach contrary to SOAP. Instead of building over the basics of Web, it tries to optimise it as it is. It uses GET to request information, and idetnfiies every single resource with a URI. This URI can now be used by anyone anywhere, a simple string that can identify and locate a resource on the Web. Not additional protocols other than HTTP and use the URIs that form the hyperlinks. Keep it simple and keep it accessible, very much goes with the ideology behind the WWW summary.

With the emergence of Web 2.0, there was search for an easier and open paradigm for using Web, which was found in REST. I am with REST for now. However I am not sure if it will be an over simplification for some problems. Only time will tell!

The RSS Blog has a good illustration of all the three protocols. I sometimes wonder if a combination of these protocols would provide a better solution in some cases. A lot of discussions end up in flaming and finger pointing. However there are some good thoughts on these:

Non-participation by W3C

It would be better if the World Wide Web Consortium (W3C) participates in creation of these paradigms and protocols. W3C is the authority and can play the role of keeping the integrity of basic principles of Web. Existence of multiple protocols is a bigger problem than just development inconvenience. It can divide the Web into incompatible parts which will ultimately be the failure of WWW.

Technorati tags: , , , , ,

Copyright Abhijit Nadgouda.

About these ads
Posted in design, web. 3 Comments »

3 Responses to “Should The Web REST Its Case?”

  1. randymorin Says:

    Interesting thought. MHO, is that many developers will refuse to use any but their favorite, solely on religious grounds. At this point, you have to make a decision as to whether it’s worth bending over for dogmatism. Sometimes it is.

  2. Abhijit Nadgouda Says:

    Yes, but loyalty to a technology or concept need not always mean higher business value. If your customer is paying for the job, his/her benefit should be the first priority, higher than personal preference.

    That is why I feel that there might be such unique cases where a combination provides highest value to the customer.

  3. Abhijit Nadgouda @ iface » Says:

    [...] Should The Web REST Its Case? [...]


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: