Spiga

Updating Twitter with cURL and Wget

Just in case you are a complete noob, let me explain one of the hottest social networking tools, a micro-blogging service called Twitter. Twitter allows you to post messages of up to 140 characters (from your browser or a variety of applications) that can be seen either by the whole Twitter world or by select Twitter users. You can follow what everyone is posting or just follow your Twitter friends. (On Twitter I am "quistuipater".)

So, first up this week is a service that all Twitterholics would love if it actually worked properly: istwitterdown.com. The home page of istwitterdown reads "Yes" or "No" depending on the status of Twitter.com. Sounds cool, but all it actually seems to be telling you is whether the server is responding to pings, which is something that is quite different from whether Twitter is actually working properly, which, at the time of writing, it isn't. Again. Actually, that should be yet again. Come on Twitter, I know it seems like rocket science, but really. . . .

At the end of this discussion we'll come back to how istwitterdown should work. . . .

Anyway, next up, a command line Twitter client. In a corporate context this is something that you might want to use to broadcast a "tweet" (that's what Twitter messages are called) for events such as status updates for a service or device.

The Twitter REST-based (Representational State Transfer) API is relatively simple, and to post a tweet all you need to perform is a straightforward HTTP POST request. (Oh great, now Twitter is going up and down like a yo-yo.)

An easy way to post to tweet from a command line is to use cURL, a free open source tool that lets you use a URL format to perform data transfers.

cURL is dauntingly overblessed with features and can handle all of the major protocols, including HTTP, HTTPS, FTP, FTPS and even LDAP and Telnet. Better still, cURL is available for a large number of operating systems, including AIX, BeOS, DOS, various flavors of BSD, a huge number of Linux distros, OS X, NetWare (our younger readers may have heard of this), Solaris and Windows (both 32- and 64-bit versions).

To post to Twitter you have to have an account because the API requires you to authenticate. So using cURL in a command or terminal window, you enter a command line as follows (this command should be on a single line and the variables are underlined):

curl -u email:passw -d status="text" http://twitter.com/statuses/update.xml

cURL figures out which protocol to use from the URL you provide, and when "http:" is specified will, unless otherwise instructed (using -0), default to using HTTP 1.1. The first argument, -u, instructs cURL to use the next two parameters (separated by a colon) as the account name and password for basic authentication. The next argument, -d, specifies the data (maximum 140 characters) to be sent via a POST request.

Of course what cURL expects is a response to the POST request so the result will be the requested page (update.xml) sent to stdout. This page will be encoded according to the file type used in the request, thus as we just requested update.xml we'll get XML-formatted data. The alternatives are JSON (JavaScript Object Notation), RSS and Atom formats.

If you'd prefer you could do the same exercise using GNU Wget. Wget, which runs on Windows, MSDOS, VMS and Solaris, is similar to cURL but with fewer features and a slightly more complex syntax. This is the same Twitter posting as above in Wget format (this command should also be on a single line):

wget --keep-session-cookies --http-user=email --http-password=passw --post-data="status=text" http://twitter.com:80/statuses/update.xml

Unlike cURL, Wget sends the output to a file named for the target of the request (here it would be update.xml).

It is important to note that you are limited to sending updates to your Twitter account no more frequently than 70 times in any 60-minute period.

So, how should istwitterdown.com work? Rather than just pinging the server, it should set up a Twitter account and, using a query similar to those above, perform an update and then check the return code. The code will show that the service will respond or the Web server will report that the server isn't running or you'll get a timeout. How hard is that?

1 comments:

  Anonymous

May 27, 2008 at 6:42 AM

Nice Article , it helped me a lot in my current project