RESTful Swing Client
Friday, March 27, 2009
Chapters 2 and 3 of my book cover RESTful Java clients. The term
RESTful Java client sounds fancier than it should be, as I
already posted a simple Java client that only requires about 5 lines of code to do everything. However, the value of web services is not connecting to them, but consuming the results--consuming results means doing something important with them.
For the later chapters, I get into the design and implementation of fully RESTful web services. Because of this, I will need something to test the code. The something is part of Chapter 2, for which I have created a generic RESTful test client that connects to any service that has a URI. Consequently, this small application can connect to any HTTP server.
Once the book is published, I will make all the code available in this site. For now, I will leave you with the screen shot that is in the book:
Dangers of Wikipedia?
Wednesday, March 25, 2009
I was looking around my site's referrer list and found something interesting and disturbing. I found one of my pages linked from Wikipedia. The link in question is
Invention and Innovation: Microsoft's Photosynth.
This is the first time I've ever been linked from Wikipedia as a source for something. I have to admit that it's flattering; however, Wikipedia is
completely wrong by attributing the creation of PhotoSynth to me. I didn't create it; I just a wrote a short description of it on my site. I re-read the entry to make sure I didn't give the impression that I had anything to do with the project (I didn't and my entry doesn't imply it either), but whoever created the Wikipedia entry completely misunderstood my entry.
We've read the stories about libelous passages on politicians profiles, but I think this attribution is similar. I will fix the entry, but I'm not sure who added it to the wikipedia article.
The article is here:
Timeline of United States inventions and discoveries.
The citations is here:
Invention and Innovation: Microsoft's Photosynth.
Again, the citation is completely wrong: I had nothing to do with that project.
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
Making Java client/server applications from standalone Java applications
Saturday, March 14, 2009
The benefits of client/server architectures are too many to list here, and going through them would detract from my main point: creating a Java distributed application from a standalone Java app that wasn't designed and coded to be one. In other words, having something that looks like this:
Look something like this:
Creating a Java application from scratch that looks like the latter diagram is not hard, for example, we can use RMI calls to exchange messages between the layers; we could use the notion of a
web service to exchange messages between each running program; or we could create our own TCP/IP client and server to exchange objects between both JVM instances.
On the other hand, making a distributed application from a compiled app with no source code seems almost impossible, or can get very complex if done by hand. Nevertheless,
j-orchestra can do it for us in no time and, more important, without writing a single line of code. Give it a try...
Do we need HTML 5?
Tuesday, March 10, 2009
As far a traditional web applications go, HTML 4 has served remarkably well. We've been able to create countless database driven applications, and, once we understood how to use Ajax calls, we began to create highly interactive applications. So why is
HTML 5 needed?
The claim is that good application will become
better. But it all depends on your application. A typical CRUD-style application doesn't really need the cherished CANVAS HTML element. We can do without it, as typical data representation is most useful in tabular form. On the other hand, having the CANVAS element uniformly available in all browsers will make things easier for web developers, since we don't have to create convoluted logic to account for IE's lack of cooperation.
Where is CANVAS needed? Mostly on graphic heavy apps, which require detailed pixel control. Will it replace Flash? Some of it. But I think Flash developers out there are already evolving with the times: pure JavaScript libraries and DHTML can already do most of what flash was used for. So, it's becoming clear that the browser will provide most of what's required off-the-box and won't need heavy plug-ins to do flashy stuff.
By the way, any incremental enhancement to any technology is a welcomed change. As long as all browser providers play by the rules, HTML 5 will be a great upgrade.
If you are from the future, watch this movie...
This is a great low-budget Sci-Fi film. I don't want to say too much, but if you are a kind of an entrepreneur or a garage tinkerer, you'll really enjoy it. Finally, if you know a bit of Physics, you'll find the dialog quite realistic; I mean that you won't cringe at every turn because they said something incredibly dumb (they say dumb things in a very believable way--yes, there is a difference).