09/20/08 :: [REST] Stu's REsponse [permalink]


Stu responded to my posts, I just want to publish his response as it is easier to read. So the text below is Stu's text:

Response to the post on RESTpolitik:


First, I will repeat a couple of points I've made before to you:

1. You opened your first paragraph with an insult, and continue to pepper your entries with ad hominem insults. JJ, I'm sorry if the politics is getting to you, but if you care at all about getting your point across, you've been going about all the wrong ways to do it.

Skimming over the past few months of posts you've made (I haven't read them all in detail, it would take a long time), you almost remind me of Nietzsche, screaming into the abyss, waiting for it to scream back at you.

2. No one of repute is suggesting that "REST is all you need". The suggestion is that REST provides a better foundation for many enterprise information system use cases than does one based on basic message exchange or RPC.

There continues to be much work to provide industry infrastructure and tooling to make this palatable to many.

Onto your specific points:

1. I think you are misreading Pete Lacey's intensions. He was not "hired" to Make REST happen: he's not even an analyst! He was a consultant. Further, he made a number of very valid arguments. His most famous post, the "S Stands for Simple", actually had nothing to do with REST, but described the crazed politics of the SOAP and WSDL world that led to the flawed technology we have today.

2. Tim Bray speaks very plainly about topics he believes in. He has been at the beginning of many technologies we now rely on, and thus is an important voice. That said, he doesn't necessarily have an opinion or understanding of the business side (some might say, "enterprise architecture") of IT. He speaks as a senior technical engineer. Yes, his voice has political impact, and you're right to challenge him on it if you don't agree. I do think, however, you've gone about it in a self-destructive manner.

3. Regarding all the stuff about "realpolitik" in standards bodies. Much of what you say resonates as true. But I'd say that it's pretty much human nature: standards wind up often being proxy battles for larger power struggles. Sometimes they can be about "rough consensus and running code", but especially in areas where money is in the air, it's hard.

4. The big difference with the REST community is that I believe you have the power struggle backwards. REST was the incumbent player, being the architecture of the web. The Web Services push was a big vendor power play trying to co-opt what already existed on the Web.

If you want to talk politics, I would argue that SOAP was arguably pushed in the 1999-2000 timeframe to give Microsoft a way to change the techno-political debate away from EJB vs. COM+ (because EJB, and Java, was winning). Instead of 'portability' it was now all about 'interoperability'. There was a kernel of truth to all of this -- would the world prefer one language and virtual machine, or still have many languages There was a kernel of truth to all of this -- would the world prefer one language and virtual machine, or still have many languages and runtimes? But it was in their interests to push the alternative while they finished the COM+ Runtime 1.0 (which became known as the .NET common language runtime).

As for .NET vs. Java interoperability? .NET didn't even exist when SOAP was introduced, let's talk VB6 vs. Java! One could do that with just an XML serialization format and HTTP. I built financial systems back in 1999-2000 in this manner; all that SOAP and WSDL gave you were an IDL and generated stubs that made you feel like you were back in COM or CORBA.

Caught in the middle was the Web architecture, which was deemed irrelevant by those fighting the battles, because they were fighting over component software standards. That hypermedia might be a new way of thinking wasn't even considered (until Google became a threat).

REST was a bottom-up change that took nearly 5 years on blogs, mailing lists, and standards bodies to get traction, and a near 7 years before it became accepted, mostly at the expense of Mark Baker's health and bank account. Through this time, REST was usually sidelined in the standards bodies (other than, perhaps, the W3C TAG). It was repeatedly misunderstood, misrepresented, and ridiculed by the powers pushing their CORBA-with-angle-brackets approach.

If you perceive some members of the REST community playing hardball technology politics, it was because they were taught by the best of them.

On your last paragraph, here's my opinion: I continue to think that most of your arguments against REST are a failure of creativity and imagination on your part, and not because REST is fundamentally flawed for enterprise systems. Instead of saying "REST can't do X", why don't you look around and ask yourself "how would I do X with hypermedia"? If you have real concerns about REST (and I think there are a couple that warrant deeper exploration, such as modeling business interactions with hypermedia), you would be well suited to stop fighting the politics and just trying to improve the technology. It plays more to your strengths. Continuing down this course, you're just screaming at the abyss.

Response to the post on "Wag the Dog"

1. Tim Berners-Lee's requirements was that the web was a global information space. He didn't design all of the aspects of enabling easy machine-processability up front, but for the past 10 years (i.e. before Roy published his thesis) he has been promoting the Semantic Web as the extensions to make this work.

http://en.wikipedia.org/wiki/Sem...ki/ Semantic_Web

"I have a dream for the Web [in which computers] become capable of analyzing all the data on the Web – the content, links, and transactions between people and computers. A ‘Semantic Web’, which should make this possible, has yet to emerge, but when it does, the day-to-day mechanisms of trade, bureaucracy and our daily lives will be handled by machines talking to machines. The ‘intelligent agents’ people have touted for ages will finally materialize."

2. The REST community is not claiming that HTTP solves all of your problems. The argument is that distributed hypermedia is a general purpose architecture and that REST provides a style that enables its global scale.

3. Regarding boundaries. Your evaluation is not correct.

Firstly, arbitrary boundaries absolutely are described all the time -- through hypermedia links. The OpenID specification, for example, creates a fairly useful approach to exchanging authenticated identity.

Secondly, submitting machine-readable POs across network authorities requires sharing a hypermedia format for doing just that sort of thing. For example, there's nothing inherently wrong with something like EDI or OAGIS as a standardized data format. Even EDI AS2 leverages fairly RESTful approaches to message confidentiality and integrity (i.e. S/MIME). The problems occur when (for example), EDI-INT AS2 tunnels the old EDI exchange message types over HTTP and URI instead of actually USING the web protocols the way they were intended to be used. They could loosen their coupling if they better leveraged URIs and specified a hypermedia format to describe the partner connections instead of requiring out-of-band agreement.

4. Regarding identity.

Firstly, once you move into autonomous systems, there is no ability, in any technology, to have globally guaranteed identity. That's the tradeoff of autonomy vs. something that's inherently federated (i.e. under the control of a central authority).

Any system that 'pretends' that identity is guaranteed is (a) being naive and will have to incorporate tremendous data matching facilities to actually maintain the quality of that identifier, or (b) under the control of a single authority with the power and will to enforce that identity.

Secondly, your example misunderstands the relationship between URI and resources. It is true that two URIs can point to the same resource, and there isn't guaranteed way to tell.

It is not true, however, that a URI can point to two separate resources, except in cases where the authority over that URI has been deliIt is not true, however, that a URI can point to two separate resources, except in cases where the authority over that URI has been deliberately negligent in maintaining its quality.

Your example, /quote/{symbol}/last, is actually a consistent resource: "the last quote for this symbol". The resulting representation may be more useful if it contained a link to the "resource for this quote as of a specific time", which might be a redirect (e.g. a 303 See Other), or embedded in the media type of the quote itself, if that media had a well-defined context for such a link. But that's not necessary if all consumers require are "the last quote for a symbol".

4.3 Query languages.

Firstly, it's complete nonsense that "REST itself cannot return collections of objects".

What could you possibly mean by this? Perhaps you mean "HTTP itself cannot return collections", which would make more sense, but that's not HTTP's job, it's a media type's job. Any number of media types could contain collections of links. There are plenty of ways of doing so, depending on your intended consumer: HTML lists, Atom feeds, etc. It's the hypermedia type that determines how state is described. Atom feeds happen to be the growing approach for doing this generically. It's not a flaw.

Secondly, "the truth is you need REST-*", again is nonsensical. The truth is that you need many hypermedia types for a variety of intended uses. Again, I question why you would have a problem with this -- of course you would need many specs for orthogonal concerns. This is no different than defining a standardized format for SOAP/WSDL in XSD, except that it leverages URIs.

If your worry is "but we've spent all of this time on the WS-* specs!", that's not my problem. The industry decided to build a tower of babel based on a shaky foundation, and deserves scorn for wasting everybody's time. It will recover, eventually (it always does).

Thirdly, regarding unidirectional links. There are many references as to why bi-directional links do not scale. Many hypertext theorists, in fact, have a bone to pick with the WWW because it broke from tradition and chose unidirectional links. Yet, this approach arguably was one of the biggest architectural wins, in that it enabled decentralized evolution of links. And there are plenty of examples of localized bi-directionality being layered on top via hypermedia (e.g. RDFa, search engines, trackbacks, etc.)

Links should not be interpreted as logical relationships unless they're described by a framework that denotes them as such. For what it's worth, RDF and OWL does a reasonable job of this.

4.4 The uniform interface

Again, you seem to miss that it's up to the hypermedia format to denote the networked state machine and potential sorts of state transitions that are available for use.

Describing actions and interactions in a "connected systems" world really would just require a general hypermedia format for doing so. I'd note that (for example) XForms are a simple way of doing such a thing in both a machine-readable AND human-readable way -- they're not about CRUD; they're about describing the input for an action.

As for "too many ways to encode an action semantic, no clear way to get the state a resource is in, most people will choose a CRUD approach", you have a point. Much REST advocacy has centred around convention and XML over HTTP. Machine-readable forms or URI templates are vastly preferable. Beyond this, the fact that there is a lack of hypermedia format to describe "business interactions" as you've described them will prevent people from designing connected systems in the way you've envisioned.

But I do not think this is a fundamental flaw in REST so much as that you haven't yet found a way to map your vision of connected systems into a hypermedia format.

Regarding versioning, I struggle to understand your point here, as this is where you get very imprecise and wordy. What does an envelope have to do with anything? Since when would I put versioning information into a SOAP header (for example)?

Regarding hypermedia, JJ, you're really missing a big piece here. Hypermedia does not require a human to interpret it. Period. It is a complete fallacy. You keep repeating this, but there are dozens of counter examples: Google processes loads of links all day long without a single human in the loop. Sure, it has the ability to associate text patterns with links, so it's not appropriate for enterprise data management. But, then we have Bloglines which very precisely processes loads of links all day long without a human, and knows what categories to put the results into. Then, let's also look at the Semantic Web, which enables you to associate logical semantics with links. Do services like Twine require human intervention? Did Microsoft buy Powerset because their semantic web search engine secretly required an army of outsourced labour?

Regarding synchronicity and directionality, I think you completely miss the point that the _data model_ of hypermedia inherently enables asynchronous communication, regardless of the specific pattern of communication between agents and servers. When you stare at one layer of the network stack to the exclusion of all else, you'll see whatever you want to see; it's like arguing that any messaging system that uses TCP is inherently synchronous (nevermind that many messaging systems use TCP over UDP). There already is support for "asynchronous" interaction on the web (see, for example, 202 Accepted).

There could be more done here, in terms of enabling event notification of resources, which has been described in the ARRESTED thesis. But I think we can do quite a lot with what we have.

Regarding legacy enterprise systems support for resource orientation, this is amusing. None of the legacy systems support your notion of "connected systems", so it's really silly that you would say it's bad thing that they don't support "resource orientation". I don't think these approaches are exclusive of the other, and in either case, there's a lot of retrofitting required.

As for the remainder of your post, there's no point in debunking it, as it's mostly repetition of claims that I've debunked before.

Basically your pints comes down to two concerns:

a) you think REST is trampling the WS-* technologies, instead of them failing on their own;
b) you think REST-* is a waste of time because we already have WS-*

Firstly, given the market clout of most enterprise vendors, you give the REST community way too much credit. Enterprises are having problems with WS-*, period, and it has nothing to do with REST.

Secondly, whether REST-* gets built or not is unknown! Certainly parts are, but for the consumer web. REST really doesn't have that much enterprise penetration yet for machine-to-machine interaction.

IMO, for the enterprise, REST is just a portent. The WS-*, BPEL, and SCA technologies basically don't do the things you're saying they can do (even with WSPER). It's certainly not the REST community that's caused this mess, we're just offering an alternative foundation. The technology you've bought into is failing -- most enterprises aren't implementing them well, and I can guarantee that almost no one has a clue what you mean by "connected systems". So, you're trying to find a scape goat. I get that. But, I think you're just trying to shoot the messenger.

I'll suggest again, that you have some good ideas with the importance of managing interactions as first class instead of jumping straight into CRUD. You would be well suited to either keep working in the WS-* community to flesh this idea out, if they'll hear you. Or you could try to map your notion of "interaction" onto hypermedia. In my opinion, there's a lot more opportunity to try out new ideas with the latter approach. As part of our ongoing debates, I've done some work on this, but have had to put it on hold due to other commitments.