TheArchitect.co.uk - Jorgen Thelin's weblog

Is REST the SQL of the Internet?

In discussions with Mark Baker on my Architecture Styles presentation, I raised the question of whether REST and SQL could be grouped together into what I termed a "Resource-oriented" architecture style.

I can see many similarities between the two approaches that suggest they can be classified into a common group:

• Both use a "uniform interface" through a defined and limited set of command verbs
  SQL = SELECT, UPDATE, DELETE, INSERT
  REST/HTTP = GET, POST, DELETE, PUT, among others.
• Both require extra "addressing" or "identity" information in addition to the command verb itself
• Both use a "query term" as the "address" to qualify the command verb
  For example, the WHERE clause in a SQL SELECT statement
  For example, the URI in the REST/HTTP GET request
• Both return an error and status code if the request cannot be processed successfully
• Both return a snapshot of data as at a particular point in time when the request executes successfully

The notion of the similarity between REST and SQL is also implicitly mentioned in Section 2.4 of Paul Prescod's notes on the "Roots of the REST/SOAP Debate"

This all seems fairly compelling logic to me suggesting that REST/HTTP and SQL can usefully be grouped into a common classification, which I termed "resource-oriented".

I guess the question still remains to be answered about whether these are real architecture styles, or just design patterns, but it certainly seems closer to the former than the latter to me.

It is also useful to look at the differences between REST and SQL, as that will suggest areas of knowledge and research that the industry will need to explore in the future:

• SQL has a standardized vocabulary for the "query terms", but REST/HTTP does not - URI's are at best semi-opaque, and there is certainly no standard way to define how to compose a URI from constituent information (for example, building up the URL for a book on Amazon.com or Barnes and Noble's web site from the ISBN)
• There is no "meta-data" available for a REST response, whereas there is always table/view descriptions available in a SQL database.
• There are no "set-oriented" constructs in REST although there are with SQL (both the notion of result sets and also joins).
• SQL has some built in vocabulary for locking resources (SELECT FOR UPDATE), whereas these are still being discussed for REST/HTTP.

  However, some locking capabilities have been added to HTTP through the WebDAV specifications, which bear some thought on how they relate to REST as a whole:

  "The WebDAV Distributed Authoring Protocol, RFC 2518, addressed these concerns by providing facilities for overwrite prevention (locking), metadata management (properties), and namespace management (copy, move, collections)."
  [ IETF WEBDAV Working Group - Charter ]

Personally, I see REST very much like the idea of "The SQL of the Internet", and I think we can get many clues on the areas for future research by looking at the way SQL itself evolved from its earliest genesis in the IBM Research Labs.

Comments welcome.