Even the package name is a warning sign, isnt it? A JCP working group to bring to the REST world all the ease of use and broad success of WS-*. I cannot help but wonder if the announcement this week of the JCP is to bring joy to the Web of Services for the Enterprise bash later this month.

Stefan Tilkov has the low down, including the wonderful quote from Mark Hadley that the goal is to bring the same ease of development for RESTful services that JAX-WS and WSIT now provide for WS-* based services., presumably with the standardization process too. I can see myself unable to browse to web site because I'm using a the 2007/02 version of a URL, and not the 2007/06. That's a little joke there that people working with WS-Addressing won't find funny, not in the least.

Stefan is nominating himself for the JCP. So is Bill de hOra. If Pete Lacey joins in, then maybe I should go in there too and we could take control. But, I don't have the faintest clue what a REST API should look like, except that

1. It must not look like JAX-RPC/JAX-WS
2. It must not pretend that you are talking to a remote object.
3. If you send and receive XML messages, being able to work at that state must be a right, not a complex undersupported option.
4. It must support non-XML data. RDF in N3, very large binary content, streamed videos. All have URLs, all are part of a REST API. The fact that SOAP only works with XML has hidden it from all the other media types out there.
5. The server side stack must not depend on a full application server to work; this thing should host in Jetty or that toy Java 6 http stack.
6. The API should not be overengineered for nonexistent future protocols. But support for XMPP alongside HTTP would be nice, as long as nobody goes for the least-common-denominator design.

There's also some process issues I'd like to address. Most centrally, the test kit must be written as an OSS project, with the source code freely available and so we can build and run tests on Gump, and so there is no barrier to anyone getting hold of it, and so being able to pass the tests and issue their own impl.

It seems to me the people who have a better idea of what to do are the Cocoon folk and Team Netkernel, not the WS projects. Yet I suspect it will be the latter is the most interested, because clearly REST is winning the battle for hearts and minds, at least outside the enterprise. The trouble is, work on WS too long and you get corrupted, you start thinking of methods and operations, not remote state.

If there is something Sun should do, it is start a TCP on the annotations to make writing a servlet easy. Even though Servlet 2.5 allows you to write a WAR file without a web.xml file, you need to do it for every servlet, even though more niche concepts (Java EE session beans, anyone?) are handled by annotation suites.

As for me, well, I'm more interested in what a good client API would look like, one that models asynchronicity and latency properly.