Hi Marc,
> Brainstorming media types I think we need:
>
> application/xml
> application/atom+xml - should we leave this to Atom toolkits ?
> application/svg+xml
> application/json
> application/x-www-form-urlencoded
> application/octet-stream
> text/plain
> text/html
> text/xml - include or just have application/xml ?
>
> +/- ?
Yes, sounds good. What about application/xhtml+xml
> For HTTP headers I propose ignoring those we already have helper
> methods for in HttpHeaders or Response/ResponseBuilder (like Cookie,
> If*, etc):
>
> General Headers:
> Transfer-Encoding
>
> Request Headers:
> Accept-*
> Authorization
> From
> Host
> User-Agent
>
> Response Headers:
> WWW-Authenticate
>
> Entity Headers:
> Content-* (excluding Location, MD5 and Range)
> Expires
>
> +/- ?
Do you want to include the listet headers or made them available?
I think we should hide the authentication headers (Authorization and
WWW-Authenticate), because authentication should be managed by the
runtime environment, if I remember right.
>>> Add response codes to Response class?
>> I think Response.OK or Response.NOT_FOUND is not very good. Status.OK
>> resp. Status.NOT_FOUND is better (or ResponseStatus.OK resp.
>> ResponseStatus.NOT_FOUND or also Response.Status.OK resp.
>> Response.Status.NOT_FOUND)
> I like Response.Status.XXX.
+1
> For status codes I'd propose we don't include every possible status
> code, just those an application is likely to use:
>
> 200, 201, 202, 204
> 301, 303, 304, 307
> 400, 401, 403, 404, 406, 409, 410, 412, 415
> 500, 503
>
> +/- ?
Why not 300 (Multiple Chices,
http://tools.ietf.org/html/rfc2616#section-10.3.1)?
Is 401 needed? The authentication is fully moved to the container, or do
I miss something?
While thinking about status 403:
What about a method SecurityContext.forbidIfNotInRole(String...) which
throws status 403, if the user does not is in at least one of the given
roles?
To allow the app developer to add his own Response data, there could
also be a method SecurityContext.isUserInOneOfRoles(String...) returning
a boolean, so that the app developer can create it's own Response.
We could also add a method SecurityContext.userInNoRole(String...) that
returns null or a ResponseBuilder with status 403, which the app
developer could enrich as he want (own entity or what ever). This is
analog to Request.evaluatePreconditions(..)
Another possibility is to manage this with an annotation containing the
roles which at least one is needed. But this complicates the algorithm
"matching request to respone method"
best regards
Stephan