I concur with Mike. I've done a few seminars on REST. Most people I talk to think that REST = POX/RPC over HTTP. They don't realize that REST is fundamentally resource-oriented rather than object-oriented, they don't understand that the interface to a RESTful service is the set of resources that it exposes rather than the set of methods, and they don't have a clue about HATEOAS. In the last six months, only two of the clients I spoke with really understood what REST was before we started the conversation. Nonetheless, I think interest in REST is growing (based on the growing number of inquiries we're getting.)
One of the key impediments to REST adoption is the dearth of tooling and frameworks that promote resource-orientation and hypermedia. Web frameworks are functional (although they typically don't discourage bad habits like stateful connections), but they really don't work for M2M interactions. JAX-RS is a basic framework for exposing objects as resources, but it's a flawed framework in terms of the tight binding between resources and objects, and it has very poor support for HATEOAS. Another key impediment to REST adoption is XML's lack of native support for hypermedia. People (inappropriately) presume that REST requires use of XML, and it's tough to return hyperlinks indicating the continuing application flow when using XML. The most frequent question I get regarding REST is how to implement end to end security. I reply by explaining that you secure RESTful interactions the same way you secure Web applications, but secure web apps typically involve a user entering a password. It gets more complicated when no human is involved. REST is likely to enjoy broader adoption when the mainstream vendors star providing RESTful frameworks (i.e., more than JAX-RS) and better end to end security mediation infrastructure for RESTful interactions. Anne On Friday, July 30, 2010, mglendin <[email protected]> wrote: > > --- In [email protected], Nick Gall > <nick.g...@...> wrote: >> >> Steve, >> >> If I listed a handful of references, then you'd ask "where are the stats to >> show they are not outliers?" I know all too well after all these years that >> NOTHING will convince you of anything. And I'm sure you feel the same way. >> :-) >> >> The survey was done, I assume, by informationweek. But Gartner has done >> similar surveys that show REST growing steadily in our enterprise client >> base over the years. >> >> -- Nick >> > > Nick/Steve, > > yes, the InformationWeek article is rather unscientific in its presentation > of the statistics, and is also around 18 months old. > > But the first thing that struck me was that still that about 1/3 of the > respondents were contructing their SOAs using something *other* than SOAP or > REST, presumably MQSeries or similar, and this number was expected to remain > pretty constant over the next 18 months. So the only reported movement was > between SOAP and REST. This I find rather surprising, but also quite > interesting! Shouldn't we be talking more about this other 1/3? > > The second point I would like to make is that it seems more likely that when > people said they were using (or planning to use) REST, they really meant just > RPC and POX over HTTP, i.e. what the Richardson Maturity Model calls "REST > Level 0". This is emphatically *not* REST, as Roy Fielding and many others > would forcibly tell you! > > In my experience, there is very little real understanding of REST within the > industry at large. For example, I ran a conference workshop on REST a couple > of months ago and although most of the 30+ attendees had *heard* of REST, > none of them could actually say what it was! > > So I would like to ask you Nick how much evidence you have of the real > adoption of REST for system-to-system communication, that is examples of > fully hypermedia driven APIs conforming to all of the REST constraints? > > I suspect that today one could count the number of such systems worldwide on > the fingers of one hand. Perhaps Steve has a point that the real *adoption* > of "Web Services" has been much more rapid and pervasive than that of [true] > REST, because it is much easier to achieve. > > Disregarding the pros and cons of the competing technical approaches for a > moment, I think this points to a real need for REST to communicate its > message more clearly so that it can be understood by the wider industry and > to generate some form of tool support from the vendors. > > I think that the present "macho" attitude of many in the REST community who > argue that "REST is so simple that you don't need tools" is rather unhelpful > to the vast majority of practitioners who just want to get their job done > with the minimum of fuss! > > And besides, I don't see how REST can be *that* simple when the real > complexities of the design of hypermedia driven APIs do not seem to be fully > understood and certainly not clearly explained, even by the experts! > > Regards, > > -Mike Glendinning. > > > > > > > > > > > > > > > > > > > > > > ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: [email protected] [email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
