I've received some interesting replies on my earlier REST posting. It looks like Sam's even done better! Here's a question for everyone: Is this URL legal according to the SOAP spec? http://keithba.com/soap.xml

I think it matters to this discussion. In fact, even if SOAP precludes this, does it preclude using URIs to point to a specific SOAP-enabled resource in general? I don't think SOAP does. Imagine this logical name: soap://keithba.com/hitCounter and this action: soap://keithba.com/hitCounter/CurrentHits

I'm leaning towards thinking that there is in fact a URI name for any particular SOAP message, and that this is the action. (WS-Routing puts the action in the message. Assume we are talking about all WS-Routing or WS-Routing-like SOAP messages.)

Ahhhhh. I've finished the entire first draft of my book! 396 pages of hard work. Let me know if you are interested in reading through it, in exchange for some critique. Here's the outline:

Part One
1. Introducing Web Services
2. XML Web Service Standards

Part Two - Implementation
3. Building Web Services with ASP.NET
4. Creating Web Service Clients
5. XML With .NET
6. Extending .NET Web Services

Part Three - Architecture
7. Transport Protocols: TCP, UDP, SMTP, and HTTP
8. Data and Format: XML and XML Schemas
9. The Protocol: SOAP
10. Description: WSDL
11. Discovery: WS-Inspection and UDDI
12. Messaging: WS-Routing and WS-Referral
13. Securing: WS-Security
14. Advanced Messaging: Reliability and Session
15. Designing XML Web Services

Dave asks why I dislike using SOAP for RPC.

Answer: mostly because I don't think tightly-coupled RPC systems scale beyond the intranet. I'd like to imagine a world where a single XML document containing my health records can travel from my insurance provider to my doctor's office to my pharmacy to myself. I'd like to imagine that only the pieces of this document relevent to their work are readable. For very sophisticated scenarios like this, I think a much more messaging orientated system is needed.

I'm sure there are exceptions to this "RPC doesn't scale" rule of mine, but in my heart, it feels like messaging scales better.

BTW, Strange: I've had Thunder road in my head the past few days as well.

Simon says: Keith throws out a complete red herring. I don't see how the RPC spec or the encoding spec are unRESTfull, the only unRESTfull thing in the SOAP spec, is the always POST HTTP binding.

Could be true. I'm not the expert on REST I should be. But it seems to me that REST a philosophy of distributed development based on URIs and resources. Seems like loosely-coupled messaging falls right into that world - to some degree. I'm not a complete expert. Aaron Swartz, who knows more than me, agrees: "When used this way, I (and I bet most REST people) would have no problem with SOAP. Perhaps we should distinguish between SOAP-the-encoding-format and SOAP-the-RPC-over-HTTP-binding. REST people are talking about the second. New encoding formats aren't even in the same game as REST."

Of course, I am now eagerly awaiting Sam's follow up to this delicious statement: I'm now convinced that one can architect a system in accordance to the principles of REST and then implement that system using RPC style, HTTP transport, POST binding, SOAP. In fact, I'll go further and state that the GoogleSearch is an instance of this."

I hope this is true.

It's been a couple weeks since any updates. ;-) Sorry about that. I've been finishing up my book. I have a big deadline on Monday.

I notice that there has been a ton of email and blog ports on REST vs. Web services. I guess the Google guys SOAP interface started everything.

Here's a query for a REST guy: SOAP can follow REST. Just take out the awful RPC and encoding stuff. SOAP is a messaging format that is loosely coupled to transport and implementation. What more could anyone ask for? Seriously, I hate using SOAP for RPC. If you take that out, how close are we?

Well, tomorrow I'm off for Tech Ed, and the first WSDL WG f2f. Then I'm flying to the first WS-I WG meeting as well.

I'm giving three talks at teched:
Building Web Services with Visual Studio .NET and the .NET Framework
Taking a Closer Look at the GXA Specifications and .NET GXA Implementations
Web Services with .NET Framework: Blackbelt

I didn't name them :-)

Later today, I'll post my slides and code from the devcon. Really. I promise.