users@jax-rs-spec.java.net

[jax-rs-spec users] Allow header discrepancy between _at_OPTIONS request and 405 Method Not Allowed exception

From: Paul Moore <paulkmoore_at_gmail.com>
Date: Wed, 17 Jul 2013 17:03:47 +0100

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