09/05/08 :: [REST] Come On [permalink]
Evidence continue to mount that the (other) REST is a complete fraud (again, nothing that I say applies to the Web (Roy's) REST. Anne Thomas Manes reports:
Miguel de Icaza's comment causes me to ruminate:
My friend Nat was wondering about this data the other day, and since this is all static data the question is: why was this data not published merely as a Sqlite database dump?
Do we really need a REST web service to static data when we already have a good query and mining language?
Maybe the only use of this REST API is to download all the data and stick it into a SQL database ;-)
Miguel's comment relate to the fact that yes you can bake in a basic (proprietary) query language in a URI syntax but that's no SQL and that without a clear support for collection (you have to use APP crutches for that), RESTful HTTP is no where near the ideal technology to implement data services. That's a (big) problem for people who are CRUDing all day. It is also quite a problem for people that claim they have a general "application protocol" that can be used to construct ANY enterprise information system, not just the Web a massive content system with islands of information.
But wait, the RESTafarians will never stop at any argument, listen to this, Anne continues:
Miguel's questions brings to mind a conversation I had recently with Peter O'Kelly regarding an emerging data model: hypermedia, which is webby and RESTful at a fundamental level.
So what is this wonderful data model that the world has ignored for so many decades?
The hypermedia data model is essentially a flat data model (i.e., no predefined hierarchical or tabular structure), and it uses hyperlinks to express relationships within the data. Every data item (or collection of data items) is identified by and accessed via a URL, and any data item can express a relationship with any other data item via a hyperlink.
An of course, Anne "thinks":
this model is much more expressive than a data model that relies on primary and foreign keys to express relationships. The question of static or dynamic content doesn't really come into play from this aspect. The data model determines what means you have at your disposal to access and navigate your way through the data. Perhaps underneath the data might be managed in a SQLLite file. On the other hand it might just be an indexed file or an enterprise-class DBMS or data generated by an application.
I have explained here the issue related to expressing relations as links. Basically, when a customer creates a purchase order, we post the new order to the /customer/{id}/orders and we return the newly created URI:
/customers/{id}/orders/{PONumber}
First, somebody getting this PO representation would "know" my proprietary way to express that it is a PO for the customer /customers/{id}
Second, this little URI scheme only works if customers and orders are co-located behind the same network location. If I want my customers to be managed by SalesForce.com and my orders by NetSuite, I am out of luck. I have no other choice than POSTing my order to NetSuite and PUTing the URI somewhere in SalesForce, aie, ouille, %^@&*(#, not good at all.
Third, I said it before, there are only so many concepts you can reify in URL syntax. When it comes to "identity" you can never be sure what is the unique ID of a customer or a PO since you use different Uniform Resource Locators to access the same information.
But of course Anne, why did nobody thought about this before? Decades of research on information modeling, wiped out overnight by REST. It is well know that Databases have never been able to return "dynamic" content, sort or filter. It is well known that data is not relational, it is of course nagivational (why don't you go talk to defunct OODBMS vendors to figure out what went wrong). The grand priest of REST, a technology that has trouble to deal with collections, have no problem making any kind of claim. Anne, why don't you get some inspiration from Steve and explain how the hypermedia data model is going to displace relational data models in the enterprise.
I think at this point I have lost any respect I ever had for the RESTafarians "Social Network" (Steve, Stefan, Tim, John, Anne and so many more), they are simply ignorant of the most fundamental information system architecture and programming model. They are in to launch a wave, with "very" special inteREST behind.
You see, there is a metamodel behind an information system. I had offered to Stefan to create this metamodel and show how RESTful HTTP and WS-* mapped to it way back almost a year ago. He declined. After all that has been said and done in the last 12 months, I understand why. If we were to express this metamodel, we would immediately understand how poorly REST supports it.
The (other) REST is a complete fraud and it has never been clearer.