Twitter Programming Using WCF & REST

Along with an easy site with which you can access your account, there are many really cool Twitter clients out there. This is thanks to an exposed API that you can use to access all of Twitter’s features. The great thing is that this API uses a technology that WCF has embraced completely; I’m talking about REST. Though you can certainly use straight network programming to access and update your Twitter account, why not use the technology that Microsoft has put all their eggs into as far as communications programming is concerned? Twitter is, after all, all about communicating, right?

Just when you thought the social site craze had reached its peak, along came a new one that practically redefined simplicity. I mean, let’s be truthful. If you were to hear the idea for Twitter before it was released, there’s a good chance you would have shrugged it off and mumbled something like, “give me a break,” or “not another one.” But Twitter demonstrates the ultimate in good ideas. Not because of what it was designed to do, but because of what it has turned into.

In fact, the one question that Twitter asks you, which you can answer in those infamous 140 characters, “What are you doing?” is no longer accurate. What used to be a glorified IM tag is now used to post location updates, movie recommendations, expressions of emotion, and even technical information. In the .NET community, many find answers to programming issues and questions by locating Twitter entries in search results. Who would have thought; blogging 140 characters at a time.

A few months ago, I received with anticipation my issue of CODE Magazine in the mail. I open it to find an article called “Twitter Programming in Visual Basic” by none other than our dear editor-in-chief, Rod Paddock. I admit having a bittersweet reaction. Rod is a superb writer, fantastic speaker, and more importantly a good friend; but I had this idea too! I found myself kneeling in the sand at an all but covered Statue of Liberty yelling… OK, I was probably watching “Planet of the Apes” at the time. In truth, I tell this story in jest because Rod wrote a great article with which I think mine perfectly overlaps. Thanks Rod, for staying away from REST! (

Rod gives you a terrific introduction to the Twitter API and shows you how to access it using conventional Web-request programming. I strongly recommend that you read his article first because it’s a great prerequisite for this one. My goal here is to take you to the next level by bringing the Twitter API into the world of WCF. I mean, we have to, right? Microsoft has defined WCF as the platform for all message-based communication and that’s exactly what Twitter and its API are, so let’s continue with what I consider a team effort between Rod and myself.

What’s Your Motivation?

OK, so some of you are probably saying, “This is a cool deviation from conventional technical articles, but why on earth would I care about accessing the Twitter API?” Fair question. In fact, I asked myself the same question when I learned about it; so here’s what convinced me. I’ve noticed the increase use that Twitter accounts have received lately. My friends use it to state where they are. My colleagues use it to post tech info. Celebrities use it to hype what they’re up to. Believe it or not, I recently learned about an upcoming KISS tour by following Gene Simmons on Twitter (cut it out, I’m a fan). Commercial product companies have Twitter accounts to post update and fix info on their products. I’ve setup a Twitter account for CodeBreeze, my product (@CodeBreeze). All of the stated contexts here have a point of origin for the broadcasting of their information. For example, many of my friends and colleagues have either blogs or Web sites where they post technical articles and information. Rock bands have Web sites to hype their tour schedules and album release dates. And product companies, of course, all have Web sites from where they sell their products.

All of these can be entry points to making Twitter posts, either manually or automatic based on data entry elsewhere. For example, I’m currently working on the next version of my company’s Web site where as soon as I post a new build of CodeBreeze, its Twitter account gets automatically updated with an entry that publicizes it. A band on tour can update their schedule on their Web site and have it update their Twitter account automatically. You can modify Windows applications to read Twitter information. For example, one of the ideas I’m toying with is showing a Twitter feed on the CodeBreeze Startup page so that it displays and allows entry of postings with a #CodeBreeze tag. The possibilities are only limited by creativity, but all of them require access to the Twitter API. See the sidebars for one of the more unique uses of Twitter I’ve ever seen.

And if none of these appeal to you, how about the fact that it’s just plain cool and fun programming!

Accessing Twitter, Redux

Twitter’s API uses a REST API. Later in the article, I’ll get into some details about REST and its context within the world of WCF. In simple terms, REST is a messaging protocol that embraces the world of HTTP by exposing its access points through conventional URLs. Just like you browse to an ASPX page to access an ASP.NET Web application that returns HTML pages, REST allows you to browse to a URL that returns data in a variety of formats. In a sense, it is not that much different from browsing to an ASPX page and getting data returned in the form of HTML markup.

The Twitter API exposes all of its interface functions in the form of a URL that gets processed by Twitter’s servers and returns POX, ATOM, or JSON formatted data. The first two are actually XML data and very readable. POX stands for Plain-Old XML and is simply a representation of the data in the simplest XML possible. ATOM is XML-based as well but formatted to the ATOM industry standard. This way, consumers prepared to read ATOM feeds can obtain data in this format and know instantly how to parse it and make it usable. JSON stands for JavaScript Object Notation and represents a serialized format for complex JavaScript objects. Data in this format can be read by a JASON-aware application and deserialized into JavaScript objects.

Interestingly enough, the format I’ll use here with WCF is the simplest one, POX. You’ll see later how nicely Twitter data in plain-old XML format maps to WCF data contracts. So what exactly does Twitter XML data look like? I’ll give you the simplest of examples by accessing a quick public feed, attached to no account in particular.

You can browse to the URL “http://www.twitter.com/public_timeline” where you’ll see the Twitter public page where if you’re not logged in, you’ll see the Twitter public feed (all non-protected Twitter updates). See Figure 1 to see what this looks like. To see this feed in raw XML format, you can browse to “http://www.Twitter.com/statuses/public_timeline.xml”. The data that gets displayed on the browser is the same as the one you see nicely formatted in the Twitter home page, but this time it’s formatted into XML as follows, as show in Figure 2.

The URL I just showed you is a REST URL. The Twitter servers are configured to intercept requests that follow a certain URL format, query their databases, and return formatted XML. Twitter exposes many URLs, each used to retrieve information or update it. In fact, the list grows on a daily basis because REST-based URLs get parsed with both static and dynamic expectations on its parts. The URL, “Twitter.com/statuses/public_timeline.xml” is entirely static, meaning this is the URL and it does not change; it does what it does. However, there is another URL that the API exposes that returns a list of entries for a given screen name. That URL is “Twitter.com/statuses/user_timeline/{screenname}.xml”.

Most of this URL remains static all the time, but the portion I defined in curly braces actually is reserved for a specific screen name. For example, my screen name is miguelcastro67 so to access my feed using the API, you can browse to the URL “Twitter.com/statuses/user_timeline/miguelcastro67.xml”. This pattern of filling in parts of the URL to determine what kind of data you want is at the very core of a REST-based API.

Many URLs in a REST-based API like Twitter are analogous to function calls in an object-based API. For example, every posting in the Twitter database has an identifier. The Twitter API exposes a URL to access a specific posting using its ID (provided you know it, of course). The URL looks like this: “Twitter.com/statuses/show/{id}.xml”, with the {id} actually replaced with a posting ID.

Some URLs may be determined by the server to cause something to happen, other than just build and return data. For example, the URL “Twitter.com/statuses/update.xml?status={text}” causes your Twitter account to be updated with a new posting whose content replaces the {text} part of the URL. An API call like this one is a bit more complex because it requires some sort of authentication to take place. In fact, if you try to access such a URL right now, the browser will ask you for security credentials. Otherwise, you could just update anyone’s Twitter account (and wouldn’t that be fun).

In Rod’s article, he showed you how to access all of the above URLs using the Web-request objects available in the .NET Framework. He also showed you how to set up some security credentials and send them to Twitter for API calls that require them. I’m a strong believer in the step-by-step method of learning something, and learning that way to access the API is definitely the first step, so once again if you haven’t read Rod’s article, I encourage you to do so. I’ll wait.

Ok, you’re back, great. Now let’s see how all this fits into the world of WCF.

By: Miguel Castro

Miguel is an architect with IDesign who specializes in architecture consulting and building .NET solutions. He is a Microsoft MVP and INETA speaker and has been a software developer for over 22 years. With a Microsoft background that goes all the way back to VB 1.0 (and QuickBasic in fact), Miguel jumped on .NET as soon as the first public Beta was released and has provided .NET solutions for clients around the country in a variety of industries. He considers himself to be a .NET Developer and Architect and has equal love for both VB and C#, and no tolerance for language bigotry. He’s spoken at numerous user groups around the country as well as developer conferences.

He’s the author of the CodeBreeze code-generator, which among things can be found on his Web site:

www.steelbluesolutions.com

Miguel currently lives in Lincoln Park, NJ with his wife Elena and his daughter Victoria.

subscriptions@infotekcg.com