@Path("/helloworld")
  public class HelloWorldResource {
    @GET
    @Produces("text/plain")
    public String getClichedMessage() {
      return "Hello World";
    }
  }

The javadoc for the annotations explains what they do in some more detail (Path, GET, Produces).

The tutorial also includes a method of running that standalone using the grizzly HTTP connector. But I’m a stick-in-the-mud. I want it to run under tomcat. So how do I do that? Again, it turns out to be fairly simple. Just add the jersey-supplied integration servlet to your web.xml.

  <servlet>
    <servlet-name>Dispatcher</servlet-name>
    <servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
    <init-param>
      <param-name>com.sun.jersey.config.property.packages</param-name>
      <param-value>net.happygiraffe.jerseytest</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
  </servlet>
 
  <servlet-mapping>
    <servlet-name>Dispatcher</servlet-name>
    <url-pattern>/*</url-pattern>
  </servlet-mapping>

I specified an extra parameter to say which package I want scanned for resources. Otherwise Jersey will scan everything in /WEB-INF/classes and /WEB-INF/lib by default. Anyway, this works a treat:

% curl -i http://localhost:8080/jerseytest/hello
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/plain
Transfer-Encoding: chunked
Date: Sat, 13 Sep 2008 20:44:41 GMT

hello world

I’m going to play with this some more. The API feels quite nice. Particularly when compared to Restlets, which I found a little bit too uniform. Mind you, the latest restlet code has its own version of JSR 311 support, so it may still be useful. It’s also actually worth checking out the JSR-311 spec, as it’s quite readable.

It also happens to be very similar to a system I wrote at work a couple of years ago using Perl and Class::DBI. The system we have at work is a bit more complicated and has more edge cases in the generated XML, particularly with regards to nesting. Looking at that article makes me wonder if we couldn’t simplify the design our protocol… But it’s already in use by so many clients, I think that would be difficult at this point.

I don’t really have much to add to the discussion, except to point at Aristotle’s choice extracts. In a sense this is all quite amusing, except for the fact that the rails people still don’t grok what they’re getting wrong.

The difference between GWA and Mozilla is that GWA pre-fetches every single link on the page if it doesn’t find a <link rel="next"> on that page.

This combines with the fact that some people have links to “delete” and “cancel” on their web sites.

Now, the HTTP spec says that if you GET a page, then that must cause no change on the server side (safe). By creating a link that deletes something, you are breaking the rules.

Of course, if browsers supported HTTP a bit better, then they’d use a DELETE verb for such an action. But even without that, you can still use a form and POST for non safe actions. It’s definitely worth bearing in mind next time you’re writing a web app.

Update: Tom Mortoel has described the problem better than I have. And also offered actual code for a solution, which helps. Also note the informative comments.

I do have one gripe through (hey, it’s software!) and that’s the lack of RESTability. I’m really keen on using REST interfaces where possible, as I’ve found them remarkably easy to reuse. Ruby appears to go some way towards this, by focusing on a very nice clean URL structure. But one key aspect is missing: dispatch on method names. As Mark Nottingham pointed out, to get a good RESTful interface, you need to dispatch on both URI and method name.

The good news is that Ruby is architected really well, so to get this kind of behaviour should simply be a case of subclass ActiveController::Base or perhaps the Dispatcher itself. I dunno. But it looks eminently doable.