On May 15, 2012, at 7:25 AM, Martin Matula wrote:
>>
>>> IMO annotations parameter should be removed from readEntity() - interceptors chain should be built by the JAX-RS runtime based on the current context - if it is in the pre-matching phase, no name-bound or dynamically bound interceptors are relevant, so only global ones would be used. If the context, already has info about the matched method, the right dynamically bound as well as name-bound interceptors should be in the chain.
>> That would mean the corresponding MBR will always get an empty array of annotations? Aren't we restricting its functionality by doing that? Again, I think the reason why we're going in this direction is because we are allowing readEntity in the pre-match phase. IMO, interceptors (as wrappers over MBR/MBW that deal with annotations from declarations) are really post-matching thingies ...
>
> I disagree. To me the main use-case for the interceptors on the receiving end is acting based on the headers (as I said multiple times).
I don't disagree with this. It is the main use case. But the fact remains, MBR can get information from the annotations as per JAX-RS 1.X. Because they can, there are likely some implementations out there that do. Any resource representation (data format) that isn't self contained _may_ take advantage of this.
Examples of formats that are _not_ self contained are EXI in schema mode and ASN.1 with an encoding like PER. In either case, external information (not contained in the request) are needed to decode a message --namely a schema/type definition. This information _could_ be provided via annotations. These cases are likely rare in the REST world, but not necessarily impossible.
> If that's too complicated to accept/agree on, you can remove the readEntity() and bufferEntity() from the API completely - that lets implementations (such as Jersey) provide a proprietary API to workaround that and define whatever semantics they like for their impl without having to reach a collective agreement. Once more experience is gained and if it proves to be useful, it can always be added to a later revision of the spec.
We've come a long way, let's not give up :) Could we revisit the use case of the form parameter that needs to be process during pre-match? Are you convinced that it is an essential use case to support?
-- Santiago