Stefan Tilkov wrote:
> I saw that the current proposal includes a way to get at HTTP headers by
> binding them to method parameters. While this is fine, I wonder what the
> thoughts are on generic header access?
>
> I think that being able to get and set HTTP headers must be possible,
> even for simple use cases.
See the following for low-level access to request headers:
https://jsr311.dev.java.net/sketches/sketch2/javax/ws/rs/core/HttpHeaders.html#getRequestHeaders()
See the following for low-level setting of response headers:
https://jsr311.dev.java.net/sketches/sketch2/javax/ws/rs/core/Response.html#header(java.lang.String,%20java.lang.Object)
> But if this is possible, should there be a
> way to have requests go through a chain of filters that do something
> based on the headers? Filters registered based on URI templates, for
> instance?
>
With the matching algorithm i just sent details on it is possible to do
this with URI templates. For a slightly different use-case, this is done
with URI parameters with the InvoiceResource Blinksale example. When
this resource is instantiated it checks if the id of the invoice (a URI
template value) exists otherwise it returns a 404 (Not found) response.
Thus sub-resources of the InvoiceResource do not need to repeat the
check to ascertain if the invoice id exists. In a sense one can view
this as an application-specific filter.
IMHO this mechanism is not meant for filters (e.g. authentication) that
operate on the HTTP request and/or response in a similar way that
Restlet specifies filters. It is really meant for application logic.
IMHO such request and/or response filters could be declared using
annotations but i think such a mechanism is out-of-scope for the current
version of this API the EG will produce.
Paul.
> I expect one obvious answer will be that this is a low-level feature,
> but I wonder if that's really true ...
>
> Stefan
> --
> Stefan Tilkov, http://www.innoq.com/blog/st/
>
> P.S.: Jérome suggested in a reply in another thread that it might be too
> early to discuss some more advanced things. I'm happy to agree, as long
> as the argument isn't reversed later :-)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_jsr311.dev.java.net
> For additional commands, e-mail: dev-help_at_jsr311.dev.java.net
>
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109