Secondly, I think a media type that can describe both human & machine-to-machine interactions and processes would be a huge win. Think of (without cringing/laughing/fainting) a cross between WS-HumanTask, BPEL, Atom/Atompub, XForms, and OpenSocial. Optimistically, it’s bursting the silos of services and BPM by putting it on a very flexible and decenatrlized foundation. If you’re a pessimist, think of it as a “bureaucracy construction kit, that sucks less”.

Third, a MIME content-level signature & encryption protocol would be nice. Think S/MIME but actually designed for HTTP and multi-party exchange.

on the other hand, if the goal is not to build a RESTful loosely coupled system, then SOAP might be a good idea, it allows to continue the past two decades of middleware/integration systems. even though it is questionable whether this integration-style approach is appropriate anymore in a world that is changing increasingly fast, and IT systems need to keep up with that. but that is an entirely different discussion…

i am a web person and not an enterprise IT person, so i am definitely missing some background in the “old days of IT computing”. but it seems to me that the big issue really is around the question whether the old strategy of “integration” is appropriate anymore, when a more loosely coupled “cooperation” architecture is possible. which is not the always the case, and for the scenarios where tightly coupled integration is required, SOAP might be good.

it was just this image of “SOAP as the way to bring REST to the non-HTTP world” that worried me, because so much of SOAP is so explicitly non RESTful that it does not sound like a terribly good idea.

so i guess this means i am still looking for references to explanations what exactly HTTP is missing that RESTful web services need. is it that HTTP uses URIs and this WG is about defining something that instead uses WS-Addressing?

Whether it makes sense to attempt this or not, I am not sure. In the IT management domain, if I was to build a REST system, I would probably do it directly over HTTP, not SOAP. Whether there are other domains (e.g. banking with more stringent security/reliability requirements) in which a SOAP-based approach to SOA makes sense, I don’t know.

But I am not trying to build a RESTful system for IT management (if Stu is right and it happens, then I’ll be more than happy to join though). More importantly, I don’t think that the people who built WS-Transfer were trying to either. They just wanted an easy way to retrieve config data from printers and servers. They were perfectly happy with these printers and servers having their specialized “start”, “stop”, “reboot”, “sleep” operations. I don’t know that they had even heard of REST.

It’s only later (I think, some MSFT people who were in on WS-T from the start can confirm/correct) that some looked at it and assumed it was an attempt to follow REST over SOAP.

You’re also asking for resources that describe why HTTP-based REST is “not an option for web services”. I don’t think there is any. What you can find, is resources that explain why it may not always be the best option (and usually present SOAP or other middleware-based approaches as the alternative). Sanjiva is one of the spokespeople for this approach. Or his colleague Paul Fremantle.

Steve Jones is another a smart guy with non-religious thoughts on this. As is Stu. Here is what a search on “SOA REST” on Stu’s blog returns. Steve Jones, Stu and Steve Vinoski had a bit of an argument around these topics over the summer. In this post I provide links to the different posts in their argument (and a suggestion that they are not that far apart).

Overall you’ll find more people who agree with Steve Vinoski and argue against the value of WS-* in most cases. The most eloquent being Pete Lacey, but he seems to have departed the topic. You can read or hear him on this at InfoQ, but in your case it would probably reinforce your current position. You may find it more interesting to hear people with different opinions.

however, i think the HTTP-based RESTful approach has a pretty good track record of building robust, large-scale systems that work well in practice. building an alternative REST universe on top of SOAP is certainly possible, but i think you would have to have really really really good arguments as to why you shouldn’t rather implement RESTful architectures in the HTTP world where there is an enormous infrastructure already existing.

could somebody point me to a resource that explain why HTTP-based REST is not an option for web services? i am really curious, and i am sure there must be some discussion going on somewhere. an admittedly quick look at the WS-Transfer and WS-RT really looks to me like a “let’s create HTTP and media types and fragment identifiers and Atom and AtomPub” agenda, and i would like to understand better what i am missing here.

There are plenty of bad things out there that haven’t caused the end of the world. “Didn’t destroy the world” is a pretty low bar.

I agree that WS-RT does not cleanly integrate with WS-Transfer. It just pretends to do so in order to be able to present itself as a successor to WS-Management. If the group is really serious about layering WS-RT cleanly on WS-Transfer, it needs to better use SOAP headers and convince IBM to stop repeating “application data goes in the body”, especially when they can’t define “application data”. The fragment support mechanism in WS-Management is a better (but not great) approach. XMLFrag is an improvement on top of WS-Management’s fragments.

Also, the problem with the “HTTP over SOAP over HTTP” dig at WS-Transfer is that one primary purpose of SOAP is to be protocol neutral. SOAP is increasingly used over transports such as UDP or JMS (and there are efforts underway at OASIS and W3C to standardize these bindings). Another way to look at this is that WS-Transfer makes *non*-HTTP environments more REST-friendly.

BTW, my crystal ball sees the same future you do for WS-Man and CMDBf :-)