The point of my web services ramble

• Yesterday, I rambled at length about web services as I've played with them thus far. I kind of ran out of steam before I got to the eventual point.

• Here are some of the cliff notes:

  • If you're going to do RPC-over-web, you might as well use XML-RPC.

  • SOAP is a failure, in my experience. It took the good bits of XML-RPC and rocketed off into space with architecture astronauts at the helm. Others have detailed this much better than I have or will.

  • In POX, the pattern of HTTP GET query parameters and XML response is fairly well trodden. But, you still need to build a bespoke handler for each service's XML - as opposed to XML-RPC's easy path straight to native scripting language data structures.

  • Unlike POX-style APIs, XML-RPC at least gives you some convenient reusable abstractions on parameter and return value marshalling without requiring you to cobble up a bespoke client library every time.

  • Of course, neither straight POX nor XML-RPC offer an easy way to reusably do authentication, error handling, or much else beyond function calls.

  • POX can use HTTP error codes and authentication, but often doesn't use either.

  • XML-RPC offers an exception mechanism, but stops at the point of offering advice of what to do with it - which is fine, really, because anything can happen when you call a function. Authentication, though, usually boils down to a couple of extra parameters on every call. That's serviceable, but I think could be better.

  • But in any case, bespoke solutions make it hard to develop reusable abstractions and conventions.

• So, that brings me around to REST - which I think has an answer to just about all of the other styles' problems. More on that soon.

Off to get some lunch with the girl, then maybe I'll finish this line of thought and think about bundling it up into a more coherent blog post.

Also, thanks for bearing with me, if you're reading this rambling. :)

Hello world. It's Saturday morning Star Trek rerun time.