In some of my previous posts I discussed Twitter and OAuth. The reason I sniffed the protocol enough to describe it here was that I wanted to build an application that posted Tweets.  Actually, I wanted to go one better – I wanted an app that would post tweets and images, via Twitter’s /1/statuses/update_with_media.xml API call. This was for a screen-capture tool.  I wanted to be able to capture an image on the screen and “Tweet it” automatically, without opening a web browser, without “logging in”, without ever seeing a little birdy from a Twitter logo.  In other words I wanted the screen capture application to connect programmatically with Twitter.

It shouldn’t be difficult to do, I figured, but when I started looking into it in August 2011, there were no libraries supporting Twitter’s update_with_media.xml, and there was skimpy documentation from Twitter.  This is just par for the course, I think. In this fast-paced social-media world, systems don’t wait for standards or documented protocols.  Systems get deployed, and the code is the documentation.  We’re in a hurry here! The actual implementation is the documentation.  Have at it, is the attitude, and good luck!  Don’t think I’m complaining – Facebook’s acquisition of Instagram provides one billion reasons why things should work this way.

With that as the backdrop I set about investigating. I found some existing code bases, that were, how shall I put it? a little crufty.  There’s a project on google’s code repository that held value, but I didn’t like the programming model. There are other options out there but nothing definitive. So I started with the google code and reworked it to provide a simpler, higher-level programming interface for the app.

What I wanted was a programming model something like this:

var request = (HttpWebRequest)WebRequest.Create(url);
var authzHeader = oauth.GenerateAuthzHeader(url, "POST");
request.Method = "POST";
request.Headers.Add("Authorization", authzHeader);
using (var response = (HttpWebResponse)request.GetResponse())
{
  if (response.StatusCode != HttpStatusCode.OK)
    MessageBox.Show("There's been a problem trying to tweet:", "!!!");
}

In other words – using OAuth adds one API call .  Just generate the header for me!  But what I found was nothing like that.

So I wrote OAuth.cs to solve that issue.  It implements the OAuth 1.0a protocol for Twitter for .NET applications, and allows desktop .NET applications to connect with Twitter very simply.

That code is available via a TweetIt app that I wrote to demonstrate the library.  It includes logic to run a web browser and programmatically do the necessary one-time copy/paste of the approval pin.  The same OAuth code is used in that screen-capture tool.

OAuth is sort of involved, with all the requirements around sorting and encoding and signing and encoding again.  There are multiple steps to the protocol, lots of artifacts like temporary tokens, access tokens, authorization verifiers, and so on.  But a programmer’s interface to the protocol need not be so complicated.