Paul,
Seems like a reasonable request to me. I suggest that you file a JIRA [
https://java.net/jira/browse/JAX_RS_SPEC] if you haven't done so yet.
Thanks.
-- Santiago
On Jul 17, 2013, at 12:03 PM, Paul Moore <paulkmoore_at_gmail.com> wrote:
> Hi all,
>
> I'm after some help with potential discrepancies in the Allow header of a particular resource.
>
> I (reasonably) have a resource which "Allows" different methods at different points in its business lifecycle.
>
> By way of (contrived) example, imagine a shopping cart which only allows a maximum of 10 items in it. The (cart sub-ordinate) items collection is POST accepting up to the point at which it has 10 items, at which point it is no longer POST accepting. The point here is that the "Allow"able methods on the collection can change with the business state. Accordingly an OPTIONS request should reflect the change in resource state i.e. for this example GET,POST,OPTIONS -> GET,OPTIONS.
>
> I understand that:
> i) I can set the Allow header appropriately in the ResponseBuilder (for a matched method), and
> ii) I can can create an @OPTIONS annotated method that implements the vagaries of the resource lifecycle, and
> iii) the "implementor" is responsible for providing generated Allow headers in a) 405 Method Not Allowed exceptions, and b) OPTIONS request where no @OPTIONS annotated method has been provided.
>
> In the Jersey implementation, the automatic Allow header is (reasonably) generated by reflection of the annotated methods for the resource. This approach obviously limits the result to *static* annotations.
>
> My point here is that whilst the spec provides for customisation of the Allow header for the @OPTIONS request, it does not provide a mechanism to allow users to supplement the automatic "Allow" generation functionality, and therefore the user is subject to the implementation as to whether these match.
>
> Explicitly, given the Jersey example, I can easily customise the @OPTIONS request response, but 405 handling is buried deep within the (internal) MethodSelectingRouter::getMethodRouter, leading to discrepancies between the dynamic @OPTIONS handling and the *static* 405 handling.
>
> So, aside from extending Jersey in some way to handle this "dynamic resource" (a discussion for another forum) I am wondering if a future revision of the spec could or should mandate some pluggable delegation mechanism for handling Allow headers.
>
> Thoughts?
>
> Best regards
>
> Paul
>
>