Thoughts on social network and its API

I have been thinking about what API meant for social networks.  Social in nutshell is about identities, sharing content and engaging with readers in two way conversation.  It made existing blogging concept easier to adopt and more accessible to millions of users.  While popularizing publishing and subscription model with social relationships, social found new exciting applications like user-reported breaking news network, 1-1 messaging networks, and photo and video sharing services.

Blogging platforms were available well before social networks.  But it took Facebook and Twitter for content publishing and subscription model to really take off.  People saw what they can do by easily sharing updates with friends and families.  Technology (publishing and subscription) disappeared in the background and the user benefit (staying connected with friends and families) emerged.

Social API on the other hand is all about allowing developers to integrate social network identities and social graphs stored in each social networking service.  Social API is there to allow other applications to incorporate what social network has done to blogging platform.  Social API made it for social applications easy to use identities, share information and get engagements from people around us.

It allowed many applications to introduce social component by plugging into social network APIs.  What could have been a run-of-the-mill word puzzle turned into real-time family room board game that could be played across cyberspace.  Flower shop applications knew before I did that my mother's birthday is coming up and reminded me to send her bouquet.  Social API instantly allowed developers to run their applications in context of user's own social graph.  These applications in turn provided richer environment for the social network and its users.

Product Management: What I would expect from API

Thanks to slower pace blog update, I have been able to spend a hour a few days a week to pick up hacking again.  I would call it hacking, not coding, and I want to draw distinction between the two because I see the difference.  More on that later.

The project is migrating email to collaboration platform.  I blogged about it earlier.  One sentence description is to take emails in Inbox and post them on enterprise collaboration platform to be shared to internal audience.  Minimum Viable Product is posting the emails that I select on my Outlook client (yes, I'm the user of this product) to collaboration platform, and have collaboration platform return the link where it's posted so that I can forward it to anyone who need to be included.  Tagging the email so that I can search easily would be nice as well.

I use Outlook client for my work, and in order to access Exchange server, I had to use C#.  I've never coded in C# before.  I don't know any C#, and that's where my hacking began.  I call it hacking because I didn't sit down to learn C#.  I had a specific goal that I had in mind, which was to use Exchange Web Service API to access Outlook Inbox messages with special tags.  I had to figure out a way to do it using C#, a language that I didn't really care to master, so I had to hack something together.  That meant I relied on Google extensively to code and troubleshoot compilation errors.  I began from working code sample, and what I have still very much resembles the sample code from MSDN.  All my hacking was done on Visual Studio, and much of credit should go to autocomplete feature of Visual Studio.

While I was doing this hacking, I learned a few things.  I wanted to share them with you to see if any of you felt the similar way.  What I'm about to share is hacker's perspective.  Someone who doesn't know the language or doesn't care to learn the language.  All they are interested in is getting the stuff to work.

These are things that I learned.

Useful API design best practice

I've been thinking a lot about API.  API is at the intersection of SaaS, consumerization of IT and applications.  As more software moves to services on the cloud, it's becoming increasingly important to interface with the hosted services.  

Analogy that I have in mind is Lego blocks.  Just as Lego blocks can be stacked to create interesting things, APIs can be chained together or nested to create interesting applications.  littleBits is a good example of mixing these two metaphors into actual product.

While researching to get quickly up to speed with the best design practice for REST API, I found the Web API Design PDF written by Brian Mulloy to be very valuable.  Mulloy shares his practical recommendation of how to design Web API.  They are immediately actionable, and makes sense overall.

Practical guide to designing easy to use Web API
by Brian Mulloy can be downloaded from this link.
Image Source: http://www.apibook.com/

Good API should make it easy to develop with API reference guide.  Great API should make the API intuitive enough so that developers can browse the guide once and start using it.

Twitter's wrong turn away from developers

Just read Twitter's announcement on Michael Sippey's further developer's guideline to Twitter API.  Their basic message can be summed up as this: Please do not look to support Twitter as social media channel from your cool new app.  Twitter is big enough, and is more interested in making money than attracting more users.

Of course you cannot say that directly.  So Sippey uses a 2x2 chart to illustrate how small impact the new API guideline will have to developers according to the third party app universe seen by Twitter.

Twitter developers can be creative and do things in upper left, lower left and lower right quadrant.  But upper right where individual tweets are displayed and new tweets can be posted by consumers, no developer creativity will be permitted by Twitter.

Google+ API: why not now?

Earlier I've written about Google+ becoming a good social news source for me.  With introduction of Explore tab, I could find interesting things getting shared on Google+.  That is enough for me to spend time on Google+, although the curated content are not custom-tailored for my interest graph.  I guess I fit the user persona that Google+ is targeting, geeky young male adults (I had to hesitate a few seconds before I used 'young' to describe my persona...).

For me Google+ is social news source.

All the arrows are pointing to Google+ platform;
then why not more open API to point content sources to it?

API strategy is a must

While researching the social networking API, I stumbled upon these slides by Sam Ramji at Apigee.  They are worth flipping through especially the first 70 slides or so.  Sam draws an interesting parallel of today's API-based application trend with Amundsen's South Pole expedition.