Some comments on Web3S

Microsoft has recently published the Web3S specification which describes a RESTful protocol for accessing Windows Live Services.


I've read about it in this Dare Obasanjo's blog entry. I've read this entry and associated Web3S FAQ with interest, simply because it's interesting to see how people are approaching the problem of creating a RESTful protocol.

I've then read some comments. I liked this one, I can learn something from there, and I didn't like much this one, as it's more about bashing the Microsoft than evaluating Web3S, except for the reference to the complexity of some URIs in Web3S documents.


I have few comments so far. I'm not a REST expert. I'm a newbie in the area of building RESTful protocols. I can say that openly, not a big deal :-). A couple of things caught my eye.


1. I liked the idea of the merge, by using PUT and the specific content type indicating to the resource handler that it's a merge, not a complete replacement. I think it's a good way to handle what seems like different flavoures of the same task : update the state.

I've seen many long discussions on why it's important not to mix POST and PUT. I tend to agree with people suggesting use GET for retrievals and POST for everything else. I think the main driving thing behind this low-REST idea is that it's not clear what is the real benefit for the WEB in general in people using PUT as opposed to POST.

So if the protocol goes to some length and makes a clear provision for when POST, PUT and DELETE should be used then it should be welcomed but IMHO the RESTful protocol should be much more conservative in introducing new verbs to handle different shades of grey given that PUT is the verb which is still probably underused and misunderstood.

That's why I thought the idea of the merge utilising the existing PUT was cool. Sam Ruby said in his comments that it makes Web3S a single user database, but I reckon some optimistic concurrency techique can be brought to the resque.

That's why I don't quite understand the necessity of introducing a new HTTP verb Update. Actually, I've read again and I think I do. I probably like more the way GData does batch updates as this avoid the introduction of the new verb. Nor do I understand the necessity of introducing a new verb Patch. Will all these new verbs bring more value to the WEB ? Or fragmentation among its users ?

2. From the spec :
"Although String Information Items (SIIs) are modeled as resources they currently do not have their own URLs and therefore are addressed only in the context of EIIs. E.g. the value of an SII would be set by setting the value of its parent EII."

It's not clear whether SIIs will one day have their own URIs, as in

http://example.net/stuff/morestuff/net.examples.articles/net.example.article(8383)/net.example.authors/net.example.author(23455)/org.example.lastname.

IMHO it will be a mistake for cases like "lastname". What value a resource like the one above can bring in isolation ? It's state will be "Smith" or "Brown".

That's it so far...