REST, Axis2, and Hypermedia

, Jun 19, 2007

Sanjiva Weerawarana:

Its easy to just create a programming model for handling basic HTTP requests. That was done years ago- in the Java world servlets and more. However, that doesn’t sovle the problem of how to handle the payload and make links that capture the state of the application in the form of those links. The part of REST which appears hard to get right at first is that of understanding how to make correct URIs and use the HTTP verbs correctly, but the really hard part IMO is how to manage the payload and have it capture links that capture the state of the application. The information Web has it a bit easy here .. the “state” is mostly captured in the current document and links just (relatively) navigate out of it - doing that for non-information-oriented RESTful applications is an order of magnitude harder. In other words, coming up with a solid programming model for resources is non-trivial .. and that’s why we’re still talking and debating about it.

IMO the real underlying problem is that as long as programmers expect to write a class and flip a switch to get a service or one or more RESTful resources then we have nothing really but RPC masquerading as something else. Both resource and service advocates would be well-off in trying to move the developer community to get past the “class is all I need” stage. If REST is successful in getting developers to get their hands dirty more power to it.

+1. And that says a lot ;-)

On June 19, 2007 10:59 PM, Joerg said:

“So what’s the advantage of modeling the system as a set of entities and relations? Well then it maps to HTTP and REST easily and trivially - each entity is a URI and the relations become links that become embedded in the representation of the resource when you GET it…OK now rewind to the world of Java or object oriented programming languages.”

Philosophical remark: Maybe what we need is a programming model that takes one of the few mathematically sound models of CS, namely relational theory, seriously (the other mathematically sound foundation is lambda calculus of course leading to functional programming). So rather than continuing with OO we need a proper programming abstraction for programming with relational algebra (entities, relations, RFD…).