It’s been an interesting couple of weeks for folks who care about RESTful web services. Dare Obasanjo kicked things off with a couple of items about the Atom Publishing Protocol (APP) and Google’s use of it for its GData project. Tim Bray bristled at Dare’s characterization of APP, and it looked like we were headed for another summer syndication flamefest. (Why do those always happen in June?) When the Web3S protocol — not the Atom Publishing Protocol — was revealed as the proposed mechanism for granting read/write access to the half-billion Hotmail contacts, Messenger buddies, and Spaces friends that comprise the Live Contacts database, I was sure it’d turn into a flamefest.
But it didn’t. And now that things have settled down a bit, I’d like to note two points that may interest the majority of folks who don’t follow the saga of RESTful web services.
First, there’s the role of the blogosphere. I’ve often talked about how the interplay of voices in the technical blogosophere models a style of professional collaboration that I expect will someday prevail more broadly. We see that happening here. Sam Ruby usefully asks whether another protocol proposed by Microsoft, SSE, might play a role in contact synchronization. Tim Bray usefully analyzes the Web3S spec and offers some excellent advice, in particular:
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.
Along with the technical back-and-forth you can see a social process at work as the always-tricky interplay between competition and cooperation gets sorted out. APP folks: “If you had concerns about APP’s capabilities, why didn’t you voice them sooner?” Microsoft folks: “Well, we were worried about seeming to interfere, but yeah, in retrospect, we should have.” Although some of us have started to take this interplay for granted, it’s still quite novel for most people, and it’s a remarkable thing.
The second point is that, technical back-and-forth notwithstanding, the purpose of Web3S is to open up walled-garden social networks. That’s been another — and more broadly inclusive — conversation in the blogosphere recently. Facebook’s ignorance of web reputation is part of the story. Here’s another, the Facebook friend finder:
In order to find people you may know on one or another of the popular webmail systems, you’re invited to lend Facebook your credentials so it can probe your address book on one of those systems. I understand why this happens, but it’s totally the wrong message about security and digital identity to be sending to a large community of young people.
From that perspective, Web3S is just a small part of a big story: opening up Live Contacts so there’s no need for this kind of impersonation. In his talk at MIX1 (MP3 here2), Yaron Goland lays out two scenarios. For one-off exchanges, there’s the contacts control which a third-party site can embed in one of its pages so people can selectively relay Live Contacts data into the page. For longer-term relationships with trusted services, people can grant the permission to read and update their Live Contacts directly, so that social activities elsewhere will be reflected in their own address books.
In both scenarios, you retain control. You never allow a service to use your name and password to impersonate you to another service. That’s a good thing for Facebook, which would rather not have to impersonate people. It’s a good thing for people who (whether they realize it or not) don’t want to be impersonated. It’s a good thing for Microsoft because the enabling platform services will become a business. It’s a good thing for RESTful web services3 because the API is RESTful. And it’s a good thing for everyone who believes that ultimately the Internet is our social network.
1 The RESTful instinct isn’t yet fully developed. Although the API discussed in the talk is RESTful, I had to extricate this URL from the MIX RSS feed because the navigational apparatus at http://sessions.visitmix.com/ doesn’t disclose it on the URL-line or in a permalink. Note to team: Let’s please make it easier for people to point to these things.
2 I had to extract the soundtrack from the video and then republish it. Note to team: Let’s please make it easier for people to hear these things.
3 I’m wondering, though, like Tim Bray, about the introduction of a new HTTP verb. The session blurb was: “Data wants to be free! So come to this technical deep dive to learn how you can POST/GET/PUT/DELETE your way into Windows Live.” There was no mention of UPDATE. Of course the spec was published in order to solicit feedback, so I’ll be interested to see what comes of that.
10 thoughts on “RESTful Live Contacts for Internet-scale social networking”
Jon – the continue lack of security, and your perfect example of what facebook (and LinkedIn, Plaxo, etc.) are doing to subvert security in the name of user friendliness (and self-servingly growing their network of course) is a shame.
As a former security paranoid (mostly recovered, but hey, they really are out to get us!), and also someone fiendishly interested in usability and user experience, it IS possible to be secure AND be usable. It’s just hard to get that across, and make them parallel priorities during development.
And where is FOAF in reputation and as a portable people network format?
Interesting times indeed – lumbering towards the future!
I have to admit that even after reading Roy’s PhD. thesis I’m still not completely sure what REST is but I am fairly sure it doesn’t require just the four standard verbs. Introducing new verbs is fine so long as they provide some axis of functionality not provided by the existing verbs. But you would have to ask Roy or Mark Baker to be sure.
“Introducing new verbs is fine so long as they provide some axis of functionality not provided by the existing verbs.”
Agreed. I think the question is only one of whether or not the interop cost of introducing an unfamiliar verb is offset by the benefit of being to express something not otherwise easily expressible by the core set. I dunno the answer but it seems like a worthwhile question.
In our case the answer was a very clear yes. In order to honors some schemas we needed a way to do an in place update that wasn’t idempotent and that is explicitly illegal for both PUT and POST. We also needed synch capabilities and that also violated PUT and POST. UPDATE solves both problems.
YarnIntroducing new HTTP verbs violates one of the key principles of REST: the Uniform Interface.
I’ll ask Mark Baker to elaborate…
I just joined Facebook (yeah, I’m behind the times) and was struck by this as well. Jaiku also prompts you for other network credentials (Google, AIM, etc.) to invite friends. Meebo, too.
What’s really missing here is some trusted third-party contact clearinghouse. From my perspective, friend widgets per network miss the bigger picture: seamless presence for all the networks. I now have two accounts on AIM, one on Yahoo! and one on MSN. How to securely manage all those contacts?
Unfortunately, I don’t think “social integrators” like Facebook, Jaiku and Meebo are going to stop doing this kind of authentication any time soon.
I was hired by Yaron to review Web3S, and one of my first comments to
him was that I thought PUT could be used in place of UPDATE. However
Yaron convinced me that he had requirements which prevented him from
using PUT in that way (his response to me was added to the FAQ).
The more interesting discussion, I think, is whether or not those
requirements should have been there in the first place. Without
redesigning Web3S from scratch under all the same constraints Yaron
had to work within, it’s impossible to say of course. No matter how
you look at it though, I don’t think it’s that big a deal; it’s not
like Web3S is using an alternate version of POST or, worse yet, GET
(hello PROPFIND! 8-).
Relax and don?t, difficulty levels of?Immune system will, Museum The culture.Strategies in place, have gone out.Non family games webmail, potential The indigenous Don Shlem nd.Deal to nouvelle, with most stories.,