Well, well, we now have two freshly-baked HTTP-based Web Resource CRUD protocols which advertise themselves as being RESTful. Microsoft’s new Web3S is designed to support remote update of Live Contacts, which is, and I quote: “the central data store in Windows Live for address book information. All Hotmail contacts, Messenger buddies and Spaces’ friends are recorded in Live Contacts. There are currently approximately 500,000,000 active address books in Live Contacts.” See Yaron Goland’s intro APP and Dare, the sitting duck (read the comments too), then the draft spec Web Structured, Schema’d & Searchable (Web3S) and its FAQ. There’s a reaction from David Ing, Not Your Father’s MData; the comments below might be a good place to aggregate more links. [Update: Yaron Goland has addressed the issues I raised here, FAQ-style, in a comment below.]
History · With all due respect to Yaron, it is really unfortunate that the first time the world heard of Web3S it was in a post of Dare’s aimed at explaining APP’s failings, which unfortunately revealed that he hadn’t read the spec and didn’t understand it. The treatment he got, especially from me, was pretty harsh; but then the post was pretty clueless, and in my experience Dare normally isn’t, so Occam’s razor naturally generated suspicion of what lay behind the content.
And guys, if you’re going to work at Microsoft, you’ll just have to accept that you’re in a world where you’re routinely suspected of the worst. It’s too late to go back and change the history that led here; they teach distrust-of-Microsoft as an MBA-level business basic these days. Learn to deal with it or find a new job.
It might have been nice if the Live team had, you know, actually tried interacting with the other group which was noisily and in public designing a general-purpose REST-based protocol, but that’s water under the bridge.
Elephant in the Room · Um... LDAP? I thought the technology for accessing and maintaining online address-books and directories was kind of well-established and there were lots of perfectly good commercial products that exist to do just this. Why re-invent the world? Anyhow, this deserves an entry in the FAQ.
Web3S · I spent an hour with the spec and the FAQ and, while there are things that make you go “Huh!?” there’s nothing obviously insane. If you decide you totally can’t model your world as collections of entries populated with hyperlinks to express relationships, well then I guess APP’s not for you. And at the level of engineering intuition, I have to say that a monster online address book does feel different at a deep level from most online “publications” (I thought that was why we had LDAP... but I repeat myself).
A Suggestion for the Web3S Team · Get yourself a test suite! APP has already been helped by the existence of code from Joe Gregorio, me, and others. Test suites matter way more than specs, in the big picture.
Design Notes · This is not a comprehensive technical review; I’m too overloaded for a deep-dive right now. Rather, it’s a series of half-cooked questions that went through my mind as I read the spec & FAQ.
LDAP? (See above).
XML and JSON... why not just use JSON? Having two serializations makes implementors’ work twice as difficult, and forces spec-writers into stinky contortions and abstractions like EII and SII; the APP spec gets to talk just about “elements” and “attributes” and is easier to read. I don’t see where, in an LDAP-like protocol, you’d need “document-like” constructs, they look mostly like relational data records; so I’d just just wrap ’em in JSON, which means you get compulsory UTF-8 too, further simplifying implementors’ lives.
If you’re going to abstract your data store as a big XML doc, mightn’t XQuery be useful? There’s already some talk of XPath.
Damn, those are some butt-ugly URIs. I guess having a straight formal mapping from data model to URI simplifies things, though, and I suspect that people mostly won’t see them anyhow. Addressability is good.
I’m having trouble sorting out this reverse-domain-name to XML-namespace mapping. In the example, you have:
<LiveContacts xmlns=”Web3SBase:com.live.livecontacts” xmlns:Web3S = “Web3S:”> … <Contacts>
But then shouldn’t the namespace of the
Contacts element be
com.live.livecontacts.contacts? Needs more digging.
Also, I suspect the invention of a new URI scheme is really misbegotten. But tons of engineering groups make that particular mistake. You might want to consult Webarch §2.4 on this subject.
In Example 2, they say “the ID is intentionally omitted” but in fact it seems to be there in a slightly variant form, 123A instead of 123ABC. Error? Or just a little more explanation needed?
I really have trouble believing that inventing the new UPDATE HTTP method is a good idea. They want to do a potentially complicated in-place update of their data structure while preserving schema-validity, which is perfectly reasonable. Furthermore, they define a “delta” data type to be used to accomplish this, which seems really architecturally sound.
So why not just use POST? All it does is say “I’m going to change the state of the system in a way that depends on lots more than just the verb.” You’re not going to be able to understand the change anyhow without a full implementation of Web3S semantics, so what value is gained by having the verb be UPDATE instead of POST?
Introducing a new HTTP verb to the Web infrastructure (firewall administrators will just love you) and to the HTTP libraries of C, C++ C#, Perl, Python, Ruby, Java, and all the other languages people use is a big fucking deal, and it would be really nice not to go there.
Order matters on the wire but not on disk? Yow, my brain hurts.
This notion of “annotation” is hard to understand, maybe they should start with some motivating examples of why you’d want this and what you’re trying to accomplish.
Open Issue 3SAFR on white-space... not sure why this is hard. You have to be clear about grammar rules inside your elements, but who cares what if any WS occurs between them?
Conclusion · I’m an APP partisan, but I’m a bigger REST partisan. I’m not close enough to the Live Contacts problem to have a useful technical opinion on how to solve it, or whether it needs something new as opposed to something that’s already here. But if they need to invent a Web interface I think it’s smart to make it RESTful.
Good luck to them; they’ll need it, and a test suite too.