--- In [email protected], Steve Jones <jones.ste...@...> wrote: > > > Ummm but isn't 5+ years enough for a good idea to gain widespread acceptance? > > This is where I struggle. The IT industry isn't that dumb and in 5 > years REST has basically gone nowhere, certainly when you compare it > against 5 years of Java or 5 years of Web Services... hell or arguably > even 5 years of Jini. > > Steve >
Although REST has gone nowhere for [more than] 5 years, that is simply because it hasn't needed to! The specification is just as valid today as it was back in 2000 or earlier. Of course REST itself, in its HTTP instantiation, defines just a system of *intermediaries* for moving information around (I wouldn't go quite so far as to use the term "transport" as that implies perhaps too much). The clue is contained within the REST term "User Agent", i.e. specifically *not* the user but an agent of the user. The true *endpoints* are the "User" and the "Origin Server" themselves, about which REST says nothing. For the original purposes of the Web, as a mostly read-only system for sharing scientific information between human researchers, this works wonderfully. Less so for the requirements of other applications where the behaviour of the "User" and "Origin Server" endpoints is actually rather important. Because of the scale of the deployed environment, evolving the technical infrastructure of the Web is now rather a difficult problem, as we have seen with the failure of HTTP-NG and the struggle of the "Web Standards" and now HTML5 movements to update and agree on even the basic technology standards on which the Web is based. I believe, however that the Web will evolve, and we will ultimately replace HTTP, but it will require a much stronger economic imperative than currently exists to do so. What has changed in the past few years is the general industry understanding of REST. I don't think this is in anyway complete as yet, but we have come a long way since the beginnings of "Web Services" in 1999 for example. The disappointing thing, from my own personal perspective, is that even though this understanding has increased, we are still just arguing over the way in which information is moved around. Indeed, we have been doing this for a very long time, with debates over the relative merits of the OSI protocol stack versus TCP/IP, DCE-RPC versus ONC-RPC, CORBA versus DCOM and now REST versus "Web Services". More recently, we have moved on to arguing over the additional benefits of the various "envelopes" in which we can move information around, for example whether data is wrapped/contained within XML, SOAP, (X)HTML or ATOM. The more interesting and in my mind more useful debate is over the semantics of what happens to the information at the endpoints: that is, what real world effects can we achieve by exchanging this information. Surely it is for these effects that we build systems in the first place and the reason we are paid to do our jobs as IT professionals? In the REST world, these semantics exists purely in the realm of "media types" and in the implementation of the actual processing endpoints such as client applications (as distinct from browsers - remember the user is not the user agent!) and servers. How should we design media types? What is the right structure for the client and server applications? What tools are needed to help design, develop and test such systems? As far as I can see, the current REST specifications and implementation frameworks being developed do not address these issues at all. In my opinion, the quicker we can get the industry onto debating these topics, the better! -Mike Glendinning.
