It’s absolutely true you can do everything using HTTP that you can do with other approaches, and vice versa.

What ends up creating these (in my view) unproductive discussions are the background assumptions.

RESTafarians assume everything is HTTP, or can be, if everyone would just agree.

Existing enterprise IT environments are not based on HTTP and do not follow the constraints of REST.

This is the real issue, and it won’t go away simply by suggesting that everyone wake up and use HTTP for everything, since it’s possible.

Web services, like them or not, were designed in large part for compatbility with existing systems.

One of the more interesting aspects of Web services is their “multi-protocol” capability but this is where the disconnect with the HTTP world also happens.

If you assume “everything is or can be HTTP” you get one set of arguments. If you assume “everything will be multi-protocol for the forseeable future” you get another set of arguments, and as they say never the twain shall meet (whatever that means ;-)

Hang on a sec. The agreement I was talking about was agreement on the data. Outside of HTML – which I’m happy to ignore for this discussion – I don’t think either REST nor SOA have any answer to the data problem, except, as Benjamin notes, in the context of “thousands of *ML” organizations.

The agreement that Web services do provide, using my 4-point model above, is #1 and #2. Agreed?

REST without standard content types is not REST, just a step along the road to REST. The political process of defining these content types remains a vitally important hard problem, and no single standards body appears set up to solve the world’s problems on this. On the other hand, there are thousands of *ML standards and mini-organisations in use around the world. A lack of central oversight certainly results in uneven quality, and that is something to be concerned about. Document-oriented SOA has the same problem in defining content types, but theoretically gains for one (Doc-SOA) are also gains for the other (REST).

In order to communicate, you have to agree. That’s fundamental. REST is a better model than the null architectural style to achieve that agreement, and it is good to see many SOA advocates quietly absorbing REST principles one at a time.

Benjamin

I agree and thought I’d been saying so all along. That was my point though: this is all done in Web Services already. We’ve got that agreement.

Are we arguing at cross purposes? Or are we violently agreeing ;-)?

I agree with you 100% that it’s critical to doing anything with REST. But I claim that it’s just as critical to doing anything with SOA/WS. Do you disagree? If not, then perhaps you can answer my question in my comment above.

My point, and one of the reasons I’m sat on this crowded fence, is that the agreement on the data format/payload is critical to doing anything with REST that compares with the levels of interoperability we’ve seen so far with WS-* between an arbitrary number of heterogeneous implementations.

So maybe to simplify this discussion: I don’t disagree with you that this can be done (and never have). I disagree with you that it’s easy to do, because it isn’t due to political factors. Try it: I have been involved with standards (not just Web Services) since 1990 and can say with some confidence that it’s darn hard to get people to agree to the levels we have managed with WS-*. I don’t see that happening around REST.

Ok, let’s break it down.

In order for two independently developed and deployed applications to interoperate, they need to agree on standardized versions of the following things;

1. transport – how bits are moved from one box to another over a network
2. message envelope – the more interesting outer packaging for the message
3. interface – the methods and modifiers (headers) that go in the envelope
4. data – the data payload that goes in the envelope

Ok so far?

When somebody sets up a Web server on the Internet to publish some data, which of those items are they using a standardized solution for? Let’s assume the data is in a proprietary format (which rules out #4 of course).

Now what if somebody else sets up a SOAP server on the Internet to make that same information available. What’s your answer now?

I’m trying to make sure we’re doing an apples-to-apples comparison, which IMO we haven’t been doing since Web services began. I agree that the data problem is hard, but I believe it’s the same problem whether you’re using the Web or Web services, so we can ignore it when comparing the two.

As for the “low level” argument, I think Mark’s real point is in contextual data like TX, security, etc… The real point of my blog was to figure out a way to redefine the problem to avoid the need for this type of contextual data at all. I just really can’t get away from security though, can’t figure out a way to redefine the problem there….any links/pointers would be appreciated.