Simple RESTful Java client and why Twitter's API is not a RESTful web service
Saturday, March 21, 2009
The clientThis is a RESTful Java client, and is as unadorned as you can get:
/*
* RESTClient.java - Mar 17, 2009
*
* Copyright (c) 2009 Jose Sandoval
*
* All rights reserved.
*/
package com.restfuljava.chapter2.command;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.net.MalformedURLException;
import java.net.URL;
import java.net.URLConnection;
public class RESTClient {
/**
* Connect to twitter REST API and get public messages.
*
* @param args
*/
public static void main(String[] args) {
try {
URL twitter = new URL("http://twitter.com/statuses/public_timeline.xml");
URLConnection tc = twitter.openConnection();
BufferedReader in = new BufferedReader(
new InputStreamReader(tc.getInputStream()));
String line;
while ((line = in.readLine()) != null) {
System.out.println(line);
}
in.close();
} catch (MalformedURLException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
}
}
}
This app connects to Twitter's web service, and returns the latest stream of public updates. The result of this call (at 5:29 PM EDT) looks like:
<statuses type="array">
<status>
<created_at>Sat Mar 21 21:29:08 +0000 2009</created_at>
<id>1367587475</id>
<text>@SDMSTYLECEO hey girl I'm at this restaurant
boycotting eating this baby cow parmesan. Lmao</text>
<source><a href="http://orangatame.com/products/
twitterberry/">TwitterBerry</a></source>
<truncated>false</truncated>
<in_reply_to_status_id>
<in_reply_to_user_id>16535504</in_reply_to_user_id>
<favorited>false</favorited>
<user>
<id>19477616</id>
<name>J Starr</name>
<screen_name>whoisjstarr</screen_name>
<description> Editorial Director, Writer/ decision maker/
super dope chick who does lots of super dope things!
Swagger, Spandex, & Semicolons! Cheeah! </description>
<location>NY</location>
<profile_image_url>http://s3.amazonaws.com/
twitter_production/profile_images/104527501/
iheart_biggerme_normal.JPG</profile_image_url>
<url></url>
<protected>false</protected>
<followers_count>181</followers_count>
</user>
</in_reply_to_status_id>
...
</status>
</statuses>
Twitter's API is not a RESTful web serviceI should point out that Twitter's API is not a RESTful web service, because of a simple design choice. The issue is that the request type of a resource's representation is part of the URI and not the HTTP protocol's request method. In this case, we have a GET request method type, but we don't have an
Accept request field that tells the service what type of response to send back. The API returns a representation that depends on the URI itself, namely:
http://twitter.com/statuses/public_timeline.xml
If we change the
.xml part of the URI to
.json we get a JSON representation instead of an XML representation. Therefore, this is not a fully RESTful web service.
Of course, this is a design choice that makes coding RESTful clients easier: we simply connect to the URI and get a valid result. However, for a distributed application to be a RESTful web service, it must adhere to
all the constraints outlined by Fielding and not just some of them--he's very adamant about web services being called RESTful that are not RESTful because they don't strictly
adhere to all the constraints.
Should Twitter continue calling the API RESTful? I guess they can call it whatever they want, but, strictly speaking, their web service is not RESTful.
Should we care, if gets the job done? Well, yes and no: in this case, the API is useful and easy to use, but it's not properly labeled.
I think it's too late for Twitter to change the API, as there are a lot of apps that use the service as it is. In other words, adhering to all the REST guidelines is no longer an option. C'est la vie...
Labels: REST
Comments:
Thanks..but that's a bit too minimal; what about PUT/POST/DELETE (at least) in Java?
Sroe, it's all in my book: http://www.josesandoval.com/book/ ;)
Looks like I'll have to buy your book! I wouldn't worry about calling it RESTful; reading Fielding's blog on the link you sent, it looks like there's a whole load of stuff about navigability which was never there in the original dissertation. In fact that post looks much more like a rant, although it espouses some fine practices. What if JJG said we can't call a web application AJAX if it didnt use all of Asynchronous Javascript and XML? Would people returning JSON have to suddenly adopt a less sexy acronym? If I use Synchronous Javascript, would I have to learn swedish to pronounce my work?
Don't worry about it; in fact lets call this Fully Fielding RESTful API a FFRESTful API :-)