Jose Sandoval Google
 Resume     Book     Software     Drawings     Home     Subscribe to RSS feed Search Web Search

Simple RESTful Java client and why Twitter's API is not a RESTful web service
Saturday, March 21, 2009

The client
This is a RESTful Java client, and is as unadorned as you can get:
* - Mar 17, 2009
* Copyright (c) 2009 Jose Sandoval
* All rights reserved.
package com.restfuljava.chapter2.command;


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("");
URLConnection tc = twitter.openConnection();
BufferedReader in = new BufferedReader(
new InputStreamReader(tc.getInputStream()));
String line;

while ((line = in.readLine()) != null) {

} catch (MalformedURLException e) {
} catch (IOException e) {
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">
<created_at>Sat Mar 21 21:29:08 +0000 2009</created_at>
<text>@SDMSTYLECEO hey girl I'm at this restaurant
boycotting eating this baby cow parmesan. Lmao</text>
<source><a href="
<name>J Starr</name>
<description> Editorial Director, Writer/ decision maker/
super dope chick who does lots of super dope things!
Swagger, Spandex, &amp; Semicolons! Cheeah! </description>


Twitter's API is not a RESTful web service
I 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:
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...


9:15 PM | 3 comment(s) |


Thanks..but that's a bit too minimal; what about PUT/POST/DELETE (at least) in Java?
By Blogger sroe, at 3:59 PM

Sroe, it's all in my 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 :-)
By Blogger sroe, at 3:24 AM

This page is powered by Blogger. Isn't yours?

© Jose Sandoval 2004-2009