Re: Adressing more error cases ?

Erik,

I was referring to the LDP spec overall.  In response to my earlier 
comments on BPRs essentially just repeating the HTTP RFC, the comment 
was made that it avoided the need for the reader to dive into RFC 2616 
which is a good point.  Yet here, the reader does to get a full picture 
including status codes and to understand status codes requires more 
pulling of the thread of the HTTP RFC.

	Andy


On 03/10/12 18:34, Wilde, Erik wrote:
> hello.
>
> On 2012-10-03 1:25 , "Andy Seaborne" <andy.seaborne@epimorphics.com> wrote:
>>> Olivier Berger <olivier.berger@it-sudparis.eu> wrote on 09/28/2012
>>> 10:41:59 AM:
>>> The intent of the submission was to add in explicit status codes when it
>>> is not obvious.  So there are some indicated and I believe that we
>>> should
>>> follow this (in other words don't repeat HTTP spec).  I'm fine with
>>> there
>>> being an issue opened but I can't see any cases in current draft that
>>> need
>>> clarity.  Perhaps if the issue was clearly in an area that was lacking
>>> or
>>> a use case that wasn't supported, that would help.
>> There ought to be a common approach - either rely on the HTTP spec or
>> put in enough text to make the LDP doc stand on its own.
>> At the moment, status codes are relying on the HTTP spec but the
>> majority of the document (e.g. section 4) contains text so that reader
>> does not need to look at the RFC.
>
> the idea of the "HTTP Problem" draft is that there ought to be both:
> well-behaving web citizens should always use appropriate HTTP status
> codes, and clients should be able to rely on the status code semantics as
> defined by HTTP, without the need to look into any specifics of the
> service. that is the rule of the uniform interface that you cannot get
> around, unless you want to violate basic REST and web principles.
>
> that does not mean, however, that there isn't *more* that could be said
> about why a specific status code was used, either generically for the
> service, or even specifically for the request. in that case, it would be
> useful to have a convention for how this could be communicated as well,
> and since it is service-specific, it needs to be documented as part of the
> media type definition describing a specific service. so far, many REST
> services have done this, but on an ad-hoc basis (defining their own
> vocabulary). "HTTP Problem" is an approach to allow media types (and thus
> services) to reuse a common pattern and vocabulary for that, and while the
> current draft is JSON-only, the core of it is the vocabulary, which of
> course can be RDFized.
>
> i hope this clarifies matters a little bit. cheers,
>
> dret.
>

Received on Wednesday, 3 October 2012 17:56:36 UTC