Blogging Roller

That's big news. A standard Java API is coming for building REST based web services. If you're an expert in REST, you can participate in it's development by signing up for the expert group. Apache, BEA, Google and Jerome Louvel (the RESTlet guy) are on-board. Here's the intro from the JSR:

JSR 311: Java (TM) API for RESTful Web Services: 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.

This JSR will aim to provide a high level easy-to use API for developers to write RESTful web services independent of the underlying technology and will allow these services to run on top of the Java EE or the Java SE platforms. The expert group will investigate whether a subset of the API can be made used with Java ME. The goal of this JSR is to provide an easy to use, declarative style of programming using annotations for developers to write REST ful Web Services and also enable low level access in cases where needed by the application.

RESTful Web Services is a relatively new area in the industry and there are still a lot of unknowns in this space. For example, a key aspect of RESTful Web Services is for the service to be stateless. However, this often requires the developer to produce boiler-plate state restoration code that could be avoided with state-aware API help. We expect the expert group to be an active and engaged group of people participating to prioritize and help drive issues to achieve the end goal of a developer friendly API.

Here are a couple more links about the new JSR:

• Elliote Rusty Harold is not exactly positive, saying "this is like asking Karl Rove and Dick Cheney to write the Democratic Party platform" but concludes with a call for participation: "are there any JSR members here who might join the working group and bring some sanity and actual REST experience to the development of the eventual specification?"
• Jerome Louvel explains the idea of REST annotations and explains that implementations will be possible with JAX-WS, Servlet API or Restlet API.
  
• Dan Diephouse says "This is excellent news - I’m glad to see people are thinking more seriously about RESTful services on Java" and "Expert group members may be interested in checking out the previous work I’ve done on Java REST annotations"
• Brian McAllister: says the JSR sounds like another case where "reasonably good developers trying to design software for presumed-incompetent developers which will in fact be used unhappily by basically competent developers."
  
• Mark Hadley addresses some of the concerns raised above and provides an interesting code example showing the REST annotations in action.
  
• Pete Lacey: "Initial thoughts: 1) Cool! 2) The servlet API is not ideal, this is needed. 3) I hope they don’t screw it up (see JAX-WS)."
• Steve Loughran: "I don't have the faintest clue what a REST API should look like, except that it must not look like JAX-RPC/JAX-WS"
• InfoQ thread: summary of news and three comments as of Thursday
  
• Paul Sandoz: "I have been wanting to work on such an API and implementation for about 5 years! [...] Now the Web zeitgeist is back and so are we :-)"

Joe Gregorio announces a new Atom Publishing Protocol Spec (draft #12) and he says it might end up being the final. I guess it's time for a new Blogapps release with APP draft #12 and ROME 0.9 support.

Plus, Joe has put together a set of new planet sites for towns in the Charlotte, NC area; all based on feeds from Google Base, Google Blogs, Google News, Craigs List, Flickr and the Weather Service. The sites look useful, but the ads combined with the minimalist design make them look a little spammy on first glance. Perhaps a short "about this site" paragraph is in order.

To design a website you need to know about HTTP, XHTML, and URIs.

To design a web application you need to know about HTTP, XHTML, and URIs.

To design a web service you need to know about XML, SOAP, WSDL, UDDI, WS-Policy, WS-Security, WS-Eventing, WS-Reliability, WS-Coordination, WS-Transaction, WS-Notification, WS-BaseNotification, WS-Topics, WS-Transfer...

What happened there?

Leonard Richardson and Sam Ruby are writing a book on REST Web Services and they're going to develop it in the open on their blogs. If you care about web services of any kind, you're going to want to follow along.

Via The Aquarium I see that Mark Hadley's work on Web Application Description Language (WADL) is now a Sun Technical Report. WADL provides a way to describe a REST based web application or service so that tools can discover services, generate proxies, etc. As I understand it, WADL is to REST as WSDL is to SOAP.

There's also something new since the last time I looked at WADL. Mark has added a section on the Atom protocol and examples that show how to use a WADL file to replace an Atom introspection document. Looks like good stuff to me. If you need an introspection doc for your REST based web service, why not use WADL?

Via Google, I found that there's also a WADL presentation on-line.

Beware the Google Web Accelerator. It will wreak havoc on the web applications that you use (Roller included). Problem is, in most webapps HTTP GET changes things (even though it shouldn't). Read all about it on <a href= "http://radar.oreilly.com/archives/2005/05/google_web_acce_1.html">O'Reilly Radar. I don't understand this. Google employs a hell of a lot of very smart people. How did they let this one slip by?

Update: I just reviewed the Roller UI and found that, at least for deletes, we do the right thing. The pattern we follow is to use a delete link (which causes a GET), but that sends you to an "Are You Sure" page which uses a POST to do the actual delete -- so Roller is probably safe from the Google Web Accelerator.