Phil Wainewright writes;

There is no alternative to messaging. Your only choice is good messaging or bad messaging.

Mostly, sure. But sometimes, when you’ve got very good messaging beneath, it becomes possible to see new patterns of communication in the aggregate. Shared memory, for example.

As I was just writing to someone in private email, if you do REST properly, you end up with a system which exhibits the properties of both messaging and shared memory styles, depending upon the configuration of the architecture you’re examining (obviously), but also depending upon how you look at it; sometimes I see distributed objects with a uniform interface (the messaging view), and sometimes I see interconnected pools of data (the shared memory view), and both are perfectly valid and complementary ways of looking at a single configuration. Some have referred to this duopoly as “Bees and Ants”.

Sean spots an old message of Don’s. Yup.

As yet another contribution to this discussion, here’s some light hearted Jeff Foxworthy style “humour” (well, my best go at it anyhow).

You know you might be using APIs, when a firewall is something you’re trying to hide from, rather than something you’re trying to help.

You know you might be using APIs, when you’re generating stubs and skeletons rather than reusing age-old network libraries.

You know you might be using APIs, when the words “transport” and “transfer” are interchangeable in your architecture.

And, the number one … erm, wrong comedian …

You know you might be using APIs, when all your services have different, erm, APIs.

Steve has been an unwitting mentor of mine for almost ten years now. I used to read his and Doug Schmidt‘s articles religiously in the mid 90s, and have enjoyed his more recent work too. I’m sure his weblog will be just as insightful.

Welcome, Steve.

I’ve been doing some work with extensible protocol envelopes recently, with a very strong emphasis on size, processing efficiency, extensibility, and evolvability. On a lark, since I’ve been thinking about it for a few years, I thought I’d try to toss in the use of RDF, just to see how far I could go with it. As it turns out, pretty far.

I’d like to be able to talk more about this now, but can’t; it’ll have to wait, because I’m being paid to do it by somebody with competitors 8-). But I can certainly pass along one rather enlightening observation that I made …

Protocols typically work with a predicate(aka header)/value tuple. If you’ve ever worked with triples though, you quickly realize the problem with a double; it’s not everything you need to know. In this case, you don’t know the subject; what has a media type, what is of length 342 bytes, what is identified by this URI? Most protocols, therefore, define their subjects not in the message, but in the specification. For example, here are some possible subjects of an HTTP message. This is fine when you’re predefining headers in a spec; there’s still a self-descriptive path from bits-on-the-wire to what-is-the-subject-of-this-header. But for extension headers, it doesn’t cut it; you’ve got a predicate (the header name) and an object (the header value), but no subject.

It would help to have RDF available to us when defining protocol extensions.

On the brand-spankin-new REST IRC channel (does anybody have the ability to set up a chump and/or log bot?), Joe Gregorio asks;

[18-Feb:17:02 jcgregorio] ok, quick question about DELETE, does success mean the URI *has* to then go 404 or 410?
[18-Feb:17:02 jcgregorio] here is the context
[18-Feb:17:02 jcgregorio] I am adding support for the AtomAPI to a wiki
[18-Feb:17:02 jcgregorio] one of the actions is to DELETE a definition
[18-Feb:17:03 jcgregorio] but as far as a wiki is concerned, *all* words exist, they just don't have definitions yet
[18-Feb:17:04 jcgregorio] for example: http://www.intertwingly.net/wiki/pie/ALongWikiWordWhichHasNeverBeenEdited
[18-Feb:17:05 jcgregorio] my implementation now gives a 200 on DELETE, which removes the definition, but doin a GET on the DELETED URI returns a valid Atom Entry with empyt content

Great question. I’d say that it’s up to the server to interpret what DELETE means (within the bounds of the RFC 2616 definition, of course). The behaviour you describe for the Wiki there is reasonable, I’d say.

A flurry of systems aching to be engulfed by the Web this week;

• XMPP
• SIP Voicemail
• LDAP
• SNMP

Welcome aboard!

I started tracking another Web services metric last night; the number of WS-I members. I’m not expecting this to bare any fruit (i.e. show the expected decline) anytime soon, as that will certainly lag the non-deployment of Web services on the Internet by at least a couple of years. But it’ll be interesting to watch when it starts moving.

AFAIK, they don’t have an “affiliate” program yet, which is something the more mature organizations will use to boost membership for a number of reasons (including waning interest in the space). That will certainly impact this metric if and when it happens.