dev@jsr311.java.net

Re: JSR311: Header and Response Code constants

From: Bill Burke <bburke_at_redhat.com>
Date: Fri, 14 Mar 2008 12:56:00 -0400

Marc Hadley wrote:
> On Mar 14, 2008, at 9:53 AM, Stephan Koops wrote:
>
>> Hi Bill,
>>> Add known headers to HttpHeaders class?
>> Yes, when there is already a class or interface with a matching name.
>> HttpHeaders.ACCEPT_LANGUAGE is good.
>
> +1, same for MediaType constants.
>
> 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 ?
>
> +/- ?
>

+1. +1 to text/xml and application/xml

> For HTTP headers I propose ignoring those we already have helper methods
> for in HttpHeaders or Response/ResponseBuilder (like Cookie, If*, etc):
>

-1 for leaving out any headers. Have them all.

> 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
>
> +/- ?
>

+1 to every header declared in RESTful WEb Services book, even the non
standard ones.


>>
>>> 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.
>
> 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
>
> +/- ?
>

-1 for leaving out status codes. Include them all.

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com