Raised
https://java.net/jira/browse/JAX_RS_SPEC-417
Thanks
Paul
On 18 July 2013 16:28, Paul Moore <paulkmoore_at_gmail.com> wrote:
> 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
>>
>>
>>
>>
>