Santiago,
Many thanks for this, I will raise a JIRA as you suggest. I wanted not to
have have missed something obvious!
I was thinking that there might be a more general requirement for
delegation of other header values e.g. ETag's, although some have more
"resource affinity" than others.
With some thoughts towards a solution I was considering an annotation based
approach (e.g. @Header(value="Allow) ) to annotate the delegate methods,
but I'm cognisant of the fact that *a* resource may be split across many
classes (as with method requests), so there may be a requirement for an
equivalent to the Method Router in order to dispatch to the appropriate
method.
Anyway, I'll raise a JIRA for the Allow header case and see where we go
from there.
With regards to progressing a solution, is this the best forum to continue
the discussion?
Many thanks
Paul
On 18 July 2013 16:00, Santiago Pericas-Geertsen <
Santiago.PericasGeertsen_at_oracle.com> wrote:
> 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
>
>
>
>