Patrick Logan looks at my not-to-be-submitted position paper for the post-SOAP Web Services workshop

I think I need to emphasise something: I am not of the belief that REST systems should "succeed" in the enterprise by adopting WSDL-to-native code conversion, native-code-to-Service API conversion, or any attempt to seamlessly map from XML to native classes. Because these are some of the fundamental problems with SOAP stacks. There is one more, and that is the emphasis that the mainstream APIs put on blocking RPC calls.

This is why those position papers that argue that WSDL2.0's REST binding solves the problems and a converged stack/client is what we need are wrong.

1. Service providers should only publish one service API, otherwise you double your support, testing and maintenance costs.
2. REST is the only model that has been shown to be robust over time and implementations.
3. It is the only one that anyone sensible should use as their public API. And as Paul Downey, points out, in today's networks, you dont have a hard split between inside and outside. You may think you are doing internal only, but it ends up being exposed.
4. REST over HTTP lets you do stuff that SOAP cannot imagine, like stream videos in exchange to a GET operation, or paste the output of an XHTML GET directly into a web page.
5. If you do SOAP behind-the-firewall only, you will end up in a mess when you decide to expose your APIs to the outside world. Take a look at the sitation Amazon is, with their original EC2 API in SOAP with WS-Security. Not only is .NET interop patchy, Java 6 support is out too

At the same time, there are some aspects of automated client stuff that would be nice. Helper code to put together the xpath's to navigate round a document, for example. Or the printf statements needed to generate URLs from various parameters. And maybe some good fault handling code. Right now if you do RESTy stuff you are mostly left to reimplement everything yourself. And that's wrong.

I'm writing up my experiences of developing and testing my first Alpine prototype, M32, in a forthcoming document, M32: the road to the Alps, which is being checked in to SVN as I go along. There's a joke in the title, BTW.

One of the things I will cover is how I built my stuff around Java1.5 future/concurrent stuff, so I don't execute an operation, I queue it and later on wait for a response. However, if you look at the source, I have a tendency to merge the queue and the wait into a single operation, so have ended up doing what looks like blocking RPC again. Why? Its easy to test in JUnit-style test methods. Anything more complex like a state machine modeling and caching attributes of the remote WSRF entity would have been hard to code, and harder to get right. Somehow Java encourages you to represent all operations with remote endpoints as method calls, because it is the thing the language makes simplest. Even if Java7 adds native XML support, I fear it lacks an adequate notion of asynchronicity.

Anyhow, I'm not going to the boston event, though I hope to hear reports of the debate. What I am doing is contemplating whether I should host a little workshop of my own, on the topic of what-is-a-good client API for REST systems, something for locals (Peter? Tony?) and other residents of the Atlantic Northwest. It'd be interesting to look at what different languages make easy/hard, and whether a state machines or continuations would be better ways to model things. No particular date; interested parties to ping me.