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

[Michael J. Giarlo]

+1

On 3/8/06, Mike Rylander <mrylander at gmail.com> wrote:
>
> +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
> _______________________________________________
> gcs-pcs-list mailing list
> gcs-pcs-list at cipolo.med.yale.edu
> http://cipolo.med.yale.edu/mailman/listinfo/gcs-pcs-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cipolo.med.yale.edu/pipermail/gcs-pcs-list/attachments/20060308/191888e6/attachment-0001.htm