You’re welcome. As for a Restlet tutorial on developerWorks, hmmm… it sounds pretty cool

Regarding JAX-RS security, there is only a SecurityContext interface that can be injected. The responsability for actual authentication and authorization is left to the parent container (Restlet, Servlet, etc.).

https://jsr311.dev.java.net/nonav/releases/0.9/javax/ws/rs/core/SecurityContext.html

Best regards,
Jerome

One thing that stands out with JSR 311 that is solved with Restlets more easily is Security– do you have insight into security w/respect to JSR 311? Is it something that will eventually make it into the spec or is it just handled by containers and JSR 250?

I’d like to add a precision. With Restlet API’s Resource class, you are not ‘forced’ to override the allow*() methods.

In fact, there are two levels, the lower one is part of Handler, Resource’s super class:
- allow*() methods
- handle*() methods

Those are dynamically discovered and invoked. It’s not necessary to override them in subclasses. You can however, support extension HTTP methods like allowMove() and handleMove() if needed.

The higher level is indeed in the Resource class:
- is/setReadable() methods used by allowGet(), allowHead()
- is/setModifiable() methods used by allowPost(), allowPut(), etc.
- getVariants() and represent(Variant) called by handleGet() and handleHead()
- storeRepresentation(Representation) called by handlePut()
- acceptRepresentation(Representation) called by handlePost()
- etc.

It’s just that by default we forbid modification methods. To change that, just call setModification(true) in your Resource subclass’s constructor.

It also allows a finer grained control as some users might have read-only access while other with have modification rights. So, this can’t always be described at developement time like in JSR-311, you might need to actually take a look at the handled request, for example for credentials.

Nice post otherwise!

Best regards,
Jerome