Status codes [was: Caveats for Web-friendly service description]

I very much agree that the list of faults has to be open. It's also 
important that the semantics of existing fault codes don't get 
trampled; e.g., it makes sense to describe the body of a 400 or 500 
response, and have some application-specific information in them.

OTOH, describing a 401 is a tricky thing, and I think I'd much prefer 
to have some "needs-authentication" metadata with the realm, etc., 
rather than explicitly calling out the status code. 401, like many 
status codes, is a very dynamic, runtime sort of thing.

See also the WebDAV ACL work;
   http://www.ietf.org/rfc/rfc3744



On Jun 1, 2005, at 4:29 PM, Marc Hadley wrote:

>> Both WDL and WADL (and perhaps others, I just happened to notice these
>> two did it) declare the list of possible response codes that a service
>> returns, ala;
>>
>> WDL: <wdl:output code="400 403 503" ref="yahoosrch:Error"/>
>>
>> WADL: <wadl:fault name="searchError" status="400 403 503"/>
>>
>> I don't think that's a very good idea, because if those descriptions 
>> are
>> used to generate client code, then that code will be inconsistent with
>> the HTTP spec since it says;
>>
>>   "applications MUST understand the class of any status code, as
>>    indicated by the first digit, and treat any unrecognized response 
>> as
>>    being equivalent to the x00 status code of that class"
>>     -- http://www.zvon.org/tmRFC/RFC2616/Output/chapter6.html#sub1
>>
>> (Alternately, if those status codes aren't used to generate code, then
>> what are they used for?  That's why I believe they should go.)
>>
> In WADL the fault elements are intended to specify an inclusive rather 
> than exclusive list. Listing a set of faults doesn't preclude use of 
> any other HTTP status code. The fault elements allow code generation 
> for the set of specific conditions listed in the description. Other 
> conditions can be handled in some more generic fashion. E.g. use of 
> fault allows generated code to support error handling like:
>
> try {
>   // some operation
> }
> catch {SearchException s) {
>   // some search error specific error handling
> }
> catch {HTTPProtocolException e) {
>   // some generic exception handling
> }
>
> Without faults you'd only be able to use the generic exception and 
> then have to go digging in that to work out what went wrong.
>
>

--
Mark Nottingham   Principal Technologist
Office of the CTO   BEA Systems

Received on Wednesday, 1 June 2005 21:07:35 UTC