Re: [Jersey] Jersey's (experimental) approach to support hypermedia constraint

From: Kevin Duffey <>
Date: Wed, 10 Feb 2010 12:34:20 -0800 (PST)

Hi all,

I've looked at the sample.. have not had the time to try it out yet. I do have a question with regard to the proposed (or future proposed) implementation.

In the sample I saw, there is the switch call that based on the order state, returns a subset of links.. and that was easy enough to understand and looks easy enough to work with. However, even tho it may return only two actual links, say get/put, does the proposed framework handle the case where a client may call a different URI or invalid method on a given URI... for example, suppose only a GET comes back for /orders/1... and the client tries calling PUT on it. What will happen? I would guess that the @PUT method handler is called (if it's implemented)... but does the framework actually block that call completely.. or does my @PUT (and all my other method type handlers) have to have some checking code to verify that the call is valid based on the current state?

I ask this because as nice as the switch() code is to return specific links based on the state, I would like to avoid having to put if() checks in every one of my handlers to make sure the call is valid given the state. I suspect tho that this is going to be required, especially given the statelessness of REST. Hence, I don't think there is some sort of cookie mechanism with subsequent calls that can be utilized by the framework itself.. to maintain the state between calls so that the framework can block calls if they are not valid given the state. Did I say state enough?