At my new job, we all take a particular specialization. One of my co-workers helps the rest of us learn about testing security while another champions the testing of internationalization. We share what we learn about our specializations with each other so that everyone benefits. When I was asked what I wanted my specialty to be, it didn’t take me 2 seconds to say, “I wanna specialize in API testing.” This means I need to know about REST (REpresenational State Transfer).
Here is the simplest explanation of REST I can muster: You use a URL to call some method that belongs to another application. So, basically, it’s using the basic http calls of POST, GET, PUT or DELETE. The data that comes back is usually either XML or JSON.
When I was at the Writing-About-Testing conference, our host, Chris McMahon knew that I was trying to brush up on REST so he put together a few slides and did a talk for the group. While he was talking about it, I noticed @fredberinger tweeting about a slidedeck for a discussion on the management of twitter’s data. It was serendipitous because Twitter uses REST heavily.
Looking through the slides led me to googling about REST and Twitter which led to a fun discovery. If you have a Mac, you have the “curl” command. Straight from the man page… “Curl offers a busload of useful tricks.” At its simplest, curl is a command for getting data. What makes curl great is that it allows you to submit commands that normally require interaction with a few screens. For example, you can use curl to submit authentication credentials. Curl will also retrieve data for you after you’ve submitted your request. It does all of this with 1 command line. In the world of shell scripting, since curl will return xml or json data, the data is easily saved off into an xml or json file.
This means that curl can be used to interact with Twitter’s api calls. Since I’m on twitter way more than I should be (my husband will back me up on this claim), I thought this would be an excellent way to do some playing with REST calls.
This document from twitter’s wiki has some examples of using REST with Curl. It’s down at number 8. I am posting my own examples as well.
Example of a GET:
“curl -u marlenac:**** http://api.twitter.com/1/statuses/friends_timeline.xml”
This gets some of the most recent updates in my timeline. I noticed that the xml retrieved 17 updates at 11:00 pm in Sydney. I’m not going to post them all, but here is a screenshot of one status update from Andrew Elliott, aka, @andrew_paradigm. There’s a lot more information here than I see in tweetdeck.
Notice that the url above ends in “xml.” One aspect of REST is that you have to know which datatypes are valid so that you can state that in the request. I’m not going to make the same call, but change the ending to “json” like so:
“curl -u marlenac:**** http://api.twitter.com/1/statuses/friends_timeline.json”
This call produces what should be the same data, but in the JSON format. If you are not familiar with JSON, it’s just another data format. If you do not like the “pointy things” aspect of xml, you might prefer JSON. Here is a screenshot of the same status update in the JSON Format.
The JSON that was returned did not have any line feeds. This would make it easier to parse since there is only a need to look for braces and commas. I inserted the line feeds in the first half of the status so that you can make sense of the data format.
Just as it is possible to get data from Twitter with REST, you can also make updates from the command line using a POST command.
“curl -u marlenac:*** -d status=”It’s a lovely day in Sydney” http://api.twitter.com/1/statuses/update.json”
Here is the JSON that resulted from that update:
This is obviously the beginning of my playing around with REST. I now have to practice using REST with the Atlassian product I test, Confluence. While I was putting this post together, I was thinking about what I would want to test in these api calls. Since I am learning about this, I welcome input about tests that I could add to this list:
- Check that the information retrieved from different data formats is the same.
- Test the different parameters that are possible with each REST url. Make sure that they work. The api should only accept well-formed parameters and if the parameter is un-usable, should return an informative error message.
- Check that authentication works and that users should only be able to make calls within their access rights.
- Test the limits of how many calls can be made.
If you look through the Twitter documentation, you will notice that the place limits on the number of calls that can be made to some URLs. This is an indication of the fact that REST can be extremely useful for obtaining lots of data for the purpose of aggregating it. This aggregated data can make a much better data source for visualizations than, for example, comma-delimited data. One reason I haven’t been doing much visualization lately is because my inner Scarlett O’Hara has vowed that as “Tufte is my witness, I will never use comma-delimited data ever again!) (You can laugh, and believe me, I understand that rules were made to be broken.)
For those who have read this entire post, here’s a special treat. If you are on a mac, you may or may not be familiar with the “say” command. Oliver Erlewein turned me onto this during our recent Weekend Testing session. If you type: say “Shall we play a game?” your mac will, vocally, ask you, “Shall we play a game.” There’s also a parameter that lets you choose the voice. I decided to try piping the REST calls I made using curl to the say command. I could “say” what happens, but that would ruin the surprise. ;) Have some fun with that.