Andrej Koelewijn

I’m sure some will not agree with my statement, and some will think, duh, that’s so obvious, but i think this needs to be said: REST is a distributed data model.

REST is not a simplified way to implement Web Services. It’s also not a way to call Remote Procedures with a Javascript friendly syntax.

Let’s look at the facts:

• REST is about resources. Resource is just another word for object, or record.
• REST is also about URLs. URLs that identify resources. Just like ids can identify objects or records.
• And, often overlooked, REST is also about links. Resources use URLs to link to other resources. Just like foreign keys can link records to other records.

Again: resources, urls, and links. Similar to records, primary keys and foreign keys. All accessible with a few standardized operations, in multiple formats.

Organisations can publish data models, which can have links to data models of other organisations. So now you can have data models that are not limited to one database inside an organisations, but spread out over a large number of organisations. A true common model for a vertical. For example, a governmental data model which integrates all data stored in different parts of the government (oops, maybe too scary…)

Now, what good is a data model, without a good way to query it?

I think Yahoo Query Lanuage (YQL) might shows us the future of query engines. It might right now not be everything we need to query REST data models, but it sure shows that it’s possible to have a query engine that allows you to query REST resources. Such a query engine would enable you to join a number of distributed resources and simply find the data your need. Something like:

select *
from   rest r1
,      rest r2
where  r1.url = "http://taxes.gov/companies"
and    r3.url = "http://sandiego.gov/companies"
and    r3.tax_company_url = r1.company

Now, there are a lot of issues to solve before this is a reality, security and performance for example, but it would be really powerful if the internet could be turned into one big database.

So, as you can see, REST is a true architectural alternative to other ways of doing SOA: message queueing and remote procedure calls. Not just a simpler alternative.

A lot more good info on REST can be found in Stefan’s Tilkov REST presentations.