On 28 July 2010 04:02, mglendin <[email protected]> wrote: > > > > > --- In > [email protected]<service-orientated-architecture%40yahoogroups.com>, > 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. >
I'm talking about adoption rather than specification evolution. > > 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. > Agreed. > > 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. > But its pathetic in comparison with Web Services. By 2004 Web Services were all over the place with pretty much all enterprises trialing them or even standardising on them. They are now a complete commodity. REST is nowhere near that level in 5 years. > > 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". > Doubly agreed... we are in IT still talking about yet another ruddy inner tube for the same old wheel, we haven't started work on the rest of the car. > > 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? > Agreed. > > 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, I completely agree with what you are saying. This is my point. The last 5 years of REST intellectuallism has move IT forwards not one jot. We still aren't dealing with contracts, semantics or anything else around interaction beyond where the technology. Business contracts? Engagement? Federation? Nope were just arguing about which shiny pipe to pour the same crap down. > -Mike Glendinning. > Steve > > >
