vote: status codes (was Re: [gcs-pcs-list] (possible) issue: what to do for redirects?)

[Mike Rylander]

+1

On 3/8/06, Daniel Chudnov <daniel.chudnov at yale.edu> wrote:
> See below for background.  This thread seems like a lifetime ago
> somehow. :)  I know I said we shouldn't revisit decisions we've already
> made, but it seems best to first consider removing all mentions of
> particular status codes from the normative portion of the spec.
>
> Please vote on this whole change as a full diff; if you don't like
> part of it for any reason, vote it down, and we'll amend for another
> vote.
>
>   -Dan
>
>
> Proposed change:
>
>  - Change the last para under How it works which now reads:
>
>    "To minimize the scope of this specification, unAPI uses existing
>    HTTP status codes with the meaning most appropriate for a particular
>    unAPI response. See the section "Notes on HTTP status codes and error
>    handling" below for a detailed summary."
>
>    ...to instead read:
>
>    "unAPI uses the response status codes defined in HTTP [RFC 2616] to
>    indicate the success or failure of an operation.   See the section
>    "Recommended HTTP status codes and error handling (non-normative)"
>    below for suggestions of particularly useful status codes."
>
>    (note: the first line is verbatim from APP.)
>
>  - In the UNAPI (no parameters) response section, first para, remove the
>    text:
>
>    "status code should be 200."
>
>  - In the UNAPI?uri=URI response section, second para, remove the text:
>
>    "status code should be 300 (Multiple Choices)"
>
>  - Retitle the "Notes on HTTP status codes and error handling" to:
>
>    "Recommended HTTP status codes and error handling (non-normative)"
>
>    ...and rewrite its content to say:
>
>    "unAPI defers to the response status codes already defined in HTTP
>    [RFC 2616].  In particular, it is recommended that unAPI implementors
>    utilize the following:
>
>    * 300 Multiple Choices - the UNAPI?uri=URI function
>
>    * 404 Not Found - requests for a URI that is not available on the
>    server
>
>    * 415 Unsupported Media Type - requests for a URI that is available
>    on the server but for a format that is not available for that URI
>
>    Note that this list is provided as a guideline to encourage consistency
>    across implementations.  All HTTP status codes are relevant for any
>    web resource; these status codes are particularly germane for unAPI."
>
>
>
>
>
> Daniel Chudnov wrote, on Mon, Mar 06, 2006 at 11:00:36AM -0500:
> > Xiaoming Liu wrote, on Mon, Mar 06, 2006 at 08:04:05AM -0700:
> > >
> > > Thanks for catching key point for me. It's really about whether these
> > > status code are recommendation/best practice, or mandatory. I am much
> > > comfortable if we put them as recommendation, therefore not part of
> > > compliance check.
> >
> > Okay, so, I think we're converging on the same point here:  we defer
> > to HTTP itself, but maybe suggest a few particular codes.  Maybe the
> > suggestions are even non-normative, and we don't require specific response
> > codes for "unAPI compliance".
> >
> > Does anyone want to take a stab at rewriting that final bit on HTTP codes?
>
> --
> Daniel Chudnov
> Yale Center for Medical Informatics
> (203) 737-5789
> _______________________________________________
> gcs-pcs-list mailing list
> gcs-pcs-list at cipolo.med.yale.edu
> http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list
>


--
Mike Rylander
mrylander at gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org