08/24/08 :: [REST] What's Missing in REST? [permalink]
I wrote this piece on the Model Driven Engineering Revolution last week. In this article I was quoting Jean Bezivin saying:
- Model engineering is the future of object technology.
- Model engineering subsumes object technology (goes beyond but does not invalidate)
- Many general principles learnt during the development of object technology may be applied to the development of model engineering
You would think in 2008, people could reflect deeply about Software Engineering and try to learn a thing or two from the past. They could start realizing that "remoting" is not a viable approach that the programming model need a major overhaul to be able to build connected systems.
So what do I read today? Dare Obasanjo comments on Dave Winer's observation:
What's missing in REST, btw, is a standard method of serializing structs, lists and scalar types. The languages we use have a lot more in common than you might think. We're all writing code, again and again, every time we support a new interface that could be written once and then baked into the kernels of our languages, and then our operating systems. Apple actually did this with Mac OS, XML-RPC support is baked in. So did Python. So if you think it's just me saying this, you should take another look.
Dare adds:
Dave has a valid point, a lot of the time communication between distributed systems is simply passing around serialized objects and/or collections of objects. In such cases, having a lightweight standard representation for serialized objects which is supported on multiple platforms would be beneficial.
No Dare, in a "connected system" (or distributed system for that matter) elements of the system "inter-act", they are not just passing around serialized "objects".
What is absolutely hilarious is Tim Bray's position on that very question:
My single most deeply-held conviction about network computing is that attempts to abstract away the underlying message traffic are in the long run doomed. So hmmm, maybe is it not only good enough to do HTTP right, maybe all you need is to face up to the fact that it’s all about message interchange, and proceed from there (of course, you’ll probably end up inventing something essentially like HTTP
So Tim, do you really think that HTTP (a browser to server application protocol) is "all about message interchange". What do you think of this latest proposal to serialize structs, lists and scalars? Aren't you telling us, right there, that WS-* got it right and that if you are stupid enough to use a browser-to-server application protocol to implement "message interchanges", you are probably in for the biggest disappointment of your life? Tim, do you think we are just a bunch of idiots ready to swallow anything you say? No, it will never look like HTTP because it will be asynchronous, peer-to-peer and inter-action oriented. HTTP is synchronous, client/server and CRUD oriented. But, hey, we are in the 21st century, we are in the Web era, anybody can say anything they want and stick it up to a Web page or an Atom feed.
This is now hopeless, I was arguing with Stu Charlton that the Remoting Bunch could easily circle for another 50 years and still face the same issues. This is the proof that in actuality they will circle for the next 50 years. This is the proof that the (other) REST is just a REmoting Supreme Travesty.
What people will do shortly is add an MVC framework on top of REST. Actually, that has already happened. We are done, the (other) REST community has come full circle, they can now remote all they want at a very low cost (free essentially): the Remoting Bunch is remoting again.
Congratulations on a job well done !