Main changes:

• Licensing scheme changed to CDDL 1.0 or LGPL 2.1 or LGPL 3.0
• New JAX-RS extension implementing the draft JSR-311
• New OAuth extension as a pluggable authentication scheme
• New XDB extension providing integration with Oracle embedded JVM

• SSL support much improved with access to new attributes
• XmlRepresentation refactored to support SAX and DOM sources
• Major TransformRepresentation refactoring (config, reuse, SAX)
• Reference class now enforces the usage of valid URI characters
• Grizzly HTTP server now support chunked encoding of responses

Updated dependencies:

• Spring to version 2.5.2
• db4o to version 7.2 (adds transparent update)
• JavaMail to version 1.4.1
• JAF to version 1.1.1

Direct contributors:

• Adam Rosien (OAuth)
• Avi Flax
• Bruno Harbulot
• Chuck Mortimore
• Dan Diephouse
• Jeroen Goubert
• Joe Nellis
• Kevin Conaway
• Marc Portier
• Marcelo Ochoa (XDB)
• Paul J. Lucas
• Peter Neubauer
• Rhett Sutphin
• Rob Heittman
• Stephan Koops (JAX-RS)
• Steve Loughran
• Yuri de Wit

Changes log:
http://www.restlet.org/documentation/1.1/changes

Download links:
http://www.restlet.org/downloads/1.1/restlet-1.1m3.zip
http://www.restlet.org/downloads/1.1/restlet-1.1m3.exe

Maven repositories:
http://maven.restlet.org is updated on the 1st and 15th of each month
http://maven.noelios.com is updated daily with new artifacts

I know Java annotations are a very controversial subject, and there are lots of different opinions regarding them.

In a general manner, i like annotations. Annotations placed on classes and methods are nice, they help a lot without much damage. A good example of well used annotations in my opinion is the Java Persistence API. It reduces a lot of the code you'd need to write and doesn't polute things too much.

However, placing annotations inside method arguments, such as in JSR-311 (first place where i saw it) starts to really mess things up. Here's an example of the use they propose:

@UriTemplate("widgets")
public class WidgetList {
@HttpMethod
@UriTemplate("offers")
WidgetList getDiscounted() {...}

@UriTemplate("{id}")
Widget findWidget(@UriParam("id") String id) {
return lookupWidget(id);
}
}

The @UriParam is the one that really bothers me here. I'm sure it must serve a good purpose for the JSR, and it probably makes some stuff easier. However, it's unquestionable that annotating this much starts to polute the code beyond the acceptable limits. In such a short piece of code we saw 5 annotations.

I'm not saying we should go back to XML files. I really prefer annotations over XML when they are used over classes and methods, much like JPA does it. However, as many other things, annotations can be misused, and in this JSR 311 example, i think they misuse them. I just hope this trend doesn't get stronger, because i think Java would get uglier with this. Just keep the simple annotations please :)

Eu estou atualmente implementando alguns web services Restful, e estou avaliando opções para alguns pedaços do desenvolvimento. Eu já sabia que existia uma JSR para web services REST, mas ainda não tinha lido a mesma.Agora há pouco li a JSR-311, que definirá padrões de implementação Java para uma API Rest, do lado do servidor. A parte de implementação de clientes será tratada em outra(s) JSR(s) .

Esta JSR é bastante interessante, e já pude ver nela o tratamento de coisas muito úteis. De principal destaque para mim está a abordagem de mapeamento de URIs em recursos e métodos e a questão do mapeamento de classes Java para dados com diversos content-types.

Em relação às URIs, há a definição de regras para mapear URIs em classes e métodos, instanciando as classes necessárias e invocando os métodos adequados. Suponha por exemplo uma requisicao HTTP PUT na URI /usuario/16728/produto/228/configuracao/. Em um protocolo definido por mim, isto representaria uma atualização nas configurações do Produto 228 para o Usuário 16728. Um ser humano consegue entender isso sem tantos problemas, mas uma implementação manual destes mapeamentos e o parsing dos parâmetros podem ser coisas bem trabalhosas. A JSR 311 utiliza várias annotations para conseguir definir o encadeamento de classes e métodos a partir da URI utilizada, e isto faz com que você consiga desenvolver em Java normalmente e ter as suas classes instanciadas e invocadas com URIs tão flexíveis quanto você queira. Muito bom ter isso como recurso, pois implementar na mão é bem trabalhoso.

Outra coisa muito interessante é a maneira de mapear classes Java para diversos content-types. Isso é algo fundamental para uma implementação Restful com bastante flexibilidade E possivelmente alta performance. A idéia por trás disso é que o servidor recebe uma requisição de um cliente e verifica quais são os content-types que o cliente aceita. Com base nestas informações, o servidor escolhe a forma que irá utilizar para transmitir os dados.

Suponha por exemplo que uma aplicação PHP está se comunicando com seu servidor, e ele lhe informa que aceita os content-types text/plain, text/xml e application/json. O servidor pode escolher qual formato utilizar para o envio e possivelmente o envio com formato json facilita bastante a aplicação PHP. Este mesmo servidor pode receber requisições de uma outra aplicação Java, que preferencialmente receberá do seu servidor um stream binário, que terá a melhor performance de todas as opções.

O uso desta abordagem dos mapeamentos em content-types permite que sua aplicação tenha ao mesmo tempo alta interoperabilidade e alta performance. Você conseguirá se comunicar com várias plataformas e aplicações diferentes, e continuará tendo a opção de alta performance, caso seja uma aplicação da mesma plataforma. Você não consegue isso com web services WS-*. Eles não têm tamanha flexibilidade.

O meu próximo passo agora será analisar com detalhes o Jersey, a implementação de referência desta JSR. A especificação em si ainda está um tanto crua, pois ainda é um early draft. Já pude ver vários pontos interessantes, mas a definição ainda está sujeita a muitas modificações. Vou avaliar agora o que o Jersey já oferece e torcer para que ele já tenha componentes fáceis de usar e flexíveis. A proposta dele é excelente, vamos ver se a implementação consegue oferecer estes recursos sem amarrar muito as decisões de projeto.

He underlines some good synergy between the Restlet project and the Glassfish project led by Sun, in term of licensing and partnership with the Grizzly NIO framework led by Jean-François Arcand.

He also draws a flattering parallel between Restlet and Hibernate projects, especially in the light of the JSR-311 effort to standardize a high-level, annotation-centric API for RESTful Web Services.

As an active member of the expert group for this JSR, I would like to mention that the Restlet API is only one source of inspiration but not a proposal. The initial API proposition was actually made by Sun, based on its SWDP prototype. There were also previous annotation-based initiatives made by third parties.

Actually, as underlined in this previous post, both APIs will end-up being complementary rather than competitors. To clarify the scopes of those various efforts, I have drawn some illustrations based on two axis:

• the level of abstraction regarding the REST/HTTP semantics, from raw HTTP headers to high-level representation negotiation.
• the processing flow abstraction, from the raw network socket to the JSR-311 resources context.

Here is the expected positioning of the JSR-311 as implemented over the Servlet AP. Note that the gap between the Servlet API and the JSR-311 will have to be filled by an adapter:

Now, here is the expected positioning of the JSR-311 API as implemented over the Restlet API:

Finally, we also plan to submit a Restlet API 2.0 to the JCP, probably in 2008. The best parallel is between the Restlet API and the Servlet API that we clearly aim to replace in the long term, as an API giving full control on the container and its connectors, fully leveraging NIO API and asynchronous request processing, while providing full support for all REST/HTTP semantics from the ground up. The API also has a unique ability to support client-side applications, without requiring direct usage of APIs such as JDK's HttpURLConnection or Apache HTTP Client.

[Update 1] The JAX-RS extension for Restlet has been added to release 1.1 M3. See the announcement and the documentation about the extension.

[Update 2] Marc Hadley, JSR-311 spec lead, has blogged about the Restlet implementation of JAX-RS.

You can check a comprehensive list of posts following the initial announce on my updated blog post. There is a clear interest from the community for such an API. Some voiced concerns about the JCP process, others about the idea of starting with a higher level API before providing a solid lower level API as a foundation. Some don't want annotations to abstract the supposed complexity of HTTP when others are afraid that the API won't be simple enough.

In general, people seem to be positive and supportive of the initiative. The expert group now has an important task in its hands. I hope we will be able to work as closely as possible with the rest of the community to gain a constant feed-back and produce a great and widely accepted API!

These annotations will provide a high-level REST API that will be supported by lower-level APIs.

The JSR expert group will be led by Marc Hadley and Paul Sandoz from Sun. Marc is the author of WADL (Web Application Description Language), a RESTful alternative to WSDL. As the lead of the Restlet project, I was invited to be part of the initial expert group for this JSR. I am looking forward to work with other experts and with anyone interested to see a better support for REST in Java.

There is one related effort named JRA (Java REST Annotations) that I am aware of. That will be one source of inspiration. Personnally, I'm hoping it will promote a deeper mapping to REST, covering the following requirements:

• Doesn"t impose any constraint on resource URIs structure.
• Support dynamic URIs based on the URI Template draft.
• Support all HTTP methods as well as extensions like in WebDAV.
• Support all media types and not just XML.
• Support multiple representations of the same resource.
• Fully embrace the resource-oriented design paradigm.

[Update 1] Another related effort I would like to mention is Sommer, led by Henry Story, which provides a mapping (via annotations) between Java objects and RDF graphs. RDF means Resource Description Framework and is the core specification of the Semantic Web. It formally describes resources (in the REST sense), their URIs and their relationships.

[Update 2] A related thread was started in the REST discussion list.

[Update 3] More links about the announce:

• The Aquarium (Sun)
  
• Alexis Moussine-Pouchkine (Sun), follow-up
• Henry Story (Sun)
  
• Dave Johnson (Sun)
  
• Elliotte Rusty Harold
• Marc Hadley (Sun, spec lead)
  
• Stefan Tilkov: 1 (InfoQ) and 2 (blog)
• Pete Lacey
• Dan Diephouse (XFire, CFX)
• Brian McCallister (Apache, Ning)
  
• Frank Sommers (Artima)
  
• Alex Blewitt (EclipseZone)
• Steve Loughran (NetKernel)
  
• Tim Bray (Sun)
• Rafael Ferreira (Sun)
• Lars Trieloff
• Paul Sandoz (Sun, spec lead)
• Seth Ladd (Ruby, RoR, Semantic Web)
• Andrew Newman (JRDF, annotations)
• David Megginson (SAX, XML)
• Panic From Fuzzy
• Dejan Bosanac (O'Reilly OnJava)
• Dan Creswell
• Scott Mark
• The Cave
• David Illsley (IBM), follow-up
• Khanderao (Oracle)

[Update 4] Interesting insights from Andrew S. Townley (anterior to JSR announcement)

• Is "REST API" An Oxymoron?

[Update 5] The JAX-RS extension for Restlet has been added to release 1.1 M3. See the announcement and the documentation about the extension.