Services and documents¶

This post is also a reminder for myself to do some real thinking on this subject, by the way.

The most recent culprits for prompting this thinkwork (which has been brewing for a while): Sean McGrath This API-centricity, more than anything else, is the logjam that needs to be broken before we can gush forth into the RESTian bits-on-the-wire world which is the future of integration IMHO. And Adam Bosworth The original impetus behind XML, at least as far as I was concerned back in 1996, was a way to exchange data between programs so that a program could become a service for another program. I saw this as a very simple idea. Keep it simple: It is hard enough to build these massively scalable services if you keep the moving parts simple, clear, and down to a small number. This is usually called the KISS principle as in keep it simple and stupid.

I found Adam's post through Tim Bray who quotes Adam: the really useful things turn out to be the simplest ones and replies with an resounding How many times do we have to re-learn this lesson?. Amen.

We did some soap-api in the eConstruct project. I didn't put much thought in it at the time, though I had a very slight preference for plain http. Soap was OK with me back then. Now they would need some serious sharpened hardware to get me to do a soap interface again.

The core of the upcoming thinkwork will be that I guess that I want to see as much information exchange as documents as possible. Electronic documents. You don't want to "call an API", you want to send over a document.

(2004-08-10:small spelling correction after re-read; be sure to read this comment)