Question about Web3S
I think I "get" the point of Web3S, it's basically a couple of guidelines for how you should interact in a RESTful, POXy manner... but what I don't get is why it ADDS complexity to something that most people tout for its ease of use and simplicity.
For example, if I make a pure RESTful service, I should expect to reach a person with an ID of 6 belonging to a group with an ID of 7 using the following nested resource URL:
/group/7/person/6
Why is Web3S's version of URLs preferable, when, the documentation itself includes URLs like this:
/someuser@example.com/LiveContacts/com.example.addressbook/com.example.contact(ABC1234)
Which gives you a contact with the ID of AVC1234 belonging to the addressbook belonging to the personsomeuser@example.com.
Don't get me wrong, I'mtrying to drink the Kool-Aid here, but I just can't figure out why the Web3S URL is preferable - what value is it adding that the defacto REST standard does not?
This is basically a balancing act. It's not something specific to web3s. More in general, what we would like to do is land on a scenario where both custom Astoria services and Microsoft services speak in the same terms so the clients can be used for either story. So we're exploring with the protocols that the folks on the Live side of the house are working on and see how to map them on top of Astoria semantics and underlying data model.
Of course, whenever you align two things there is a bit of pain that both parts take. The trick is to make sure that the trade off between the pain you take by compromising certain design aspects is less than the value you get from the alignment.
We do understand that URIs are a bit more complex. There is a compact form of the URIs that are a bit nicer. We'll post the details about the URI format next in the blog, which will add a piece of the picture we started to paint with the protocols/formats post.
In the end, we're posting this publicly because we'd love to hear your feedback about the choice of protocols, the trade-offs, aligment decisions, etc.
Pablo Castro
Technical Lead
Microsoft Corporation
http://blogs.msdn.com/pablo
I think Pablo articulated this well in that our approach had tobalance a few factors while keeping an eye on an enabling a unified developer experience where possible accross customer and public/hosted services. As a precursor to the blog post Pablo meantioned and to address the specific example you note above: to enable iterop with a range of service using varying data models, we had to enable an addressing scheme which allows heterogenous sets as well as namespace qualified set/resource names. While Astoria servers will always use homogenous sets (ie. Customers collection contains Customer objects), this is not the case for all schemas our Live services wish to expose. I'll go into more detail in a blog that should go up to our team blog later today: http://blogs.msdn.com/astoriateam
-Mike
