Elliotte Rusty Harold nails it on the head with his opinion of JSR311 . From the JSR311 abstract:

This API will enable developers to rapidly build Web applications in Java that are characteristic of the best designed parts of the Web. This JSR will develop an API for providing REST(Representational State Transfer - See reference to Roy Fielding's dissertation in section 3.1) support in the Java Platform. Lightweight, RESTful approaches are emerging as a popular alternative to SOAP-based technologies for deployment of services on the internet. Currently, building RESTful Web services using the Java Platform is significantly more complex than building SOAP-based services and requires using low-level APIs like Servlets or the dynamic JAX-WS APIs. Correct implementation requires a high level of HTTP knowledge on the developer's part.

I know that Sun loves building new APIs but the whole point of REST is to make it easier than SOAP and the mess that is WS-* (and unsurprisingly, WS-* makes it into the top 10 XML predictions for 2007 as the year everyone gives up on it). So how can Sun claim that it's more complex? With all the mess that's gone into the WS-* specs (e.g. attributes for values are defined after the nested entities, because that's the order they came in DTDs, despite making no sense in doing that) the only people really winning in the WS-* space are the tool makers that churn out reams of XML code.

The general idea of REST (and you should take time out to read Roy Fielding's PhD thesis on the subject if you haven't done so already) is to make URLs associate with specific items, and to use PUT as well as GET and DELETE to be able to iteract, and not cookie-based state or server-side hooks.

This is already here; the Blogger API is a REST-ful one, as are the feeds that are accessed by some of the other Google toolsets (e.g. Google Base). And it's no surprise that the Atom format has been pushing for REST with the Atom Publishing Protocol as a mechanism for uploading entries and data to a remote system; indeed, there's already an Apache project Abdera project that aims to provide an Atom Publishing Protocol server.

My personal opinion is similar to Elliotte's:

A major selling point of REST is that it's simple. It doesn't require big, complicated frameworks with seven levels of indirection to solve simple problems. However there are some companies (Sun being one of them) that can't imagine regular, ordinary developers building systems without using some ultra-complex framework they've designed. The idea that people might just want to send plain old XML over plain old HTTP is inconceivable to them. There has to be some big framework for serializing objects and abstracting databases and faking method calls and guaranteeing message delivery and a dozen other things people either can already do perfectly well with HTTP and XML or don't actually need to do at all.

Anyway, comments are invited if you want to comment on JSR 311 . But Sun still haven't learned to separate out the VM from the core libraries, which will no doubt mean that this is only available to Java 8 or whatever it will be called by then, and thus generally ignored by the Java population at large. Somewhat reminiscent of other JSRs to be honest...

Incidentally (and the vague tangential link to Eclipse), I personally think that the update site should be an atom feed . Why not let your system publish an Atom entry to an Atom publishing server with the metadata for your plugin? Then an update site can easily query existing Atom feeds, and existing servers (such as PlanetEclipse ) can perform aggregation automatically to multiple subscribers. If you think this is a good idea too, add your comments or vote on bug 127236 .

Alex.