Anne, On Aug 5, 2010, at 2:54 PM, Anne Thomas Manes wrote:
> 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, What do you mean by 'tight binding between resources and objects'? > and it has very poor support for > HATEOAS. I do not think that frameworks actually can really do much in that regard. Payloads need to be more or less domain specific (meaning use of specific media types rather that generic ones such as application/json or application/xml) when you want to build a RESTful system. Hence frameworks can't really do much at the general level when it comes to payload generation. Except maybe to provide an API to plug in media type specific components. In fact, I think that JAX-RS really is headed in the right direction. > 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. Huh? I'd say it is actually pretty easy to define hypermedia controls in XML-based media types (see HTML, AtomPub, RSS). > > 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. Do you mean because you end up using some sort of system-user credentials? > > REST is likely to enjoy broader adoption when the mainstream vendors > star providing RESTful frameworks (i.e., more than JAX-RS) Can you specify what 'more' would involve? > and better > end to end security mediation infrastructure for RESTful interactions. Any sketch how that might look like? Jan > > 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 > > > ----------------------------------- Jan Algermissen, Consultant NORD Software Consulting Mail: [email protected] Blog: http://www.nordsc.com/blog/ Work: http://www.nordsc.com/ -----------------------------------
