On 12-Jul-19 10:52, Adam Roach wrote:
> On 7/11/19 3:05 PM, Michael Richardson wrote:
>> <#secure method=pgpmime mode=sign>
>>
>> Adam Roach via Datatracker <[email protected]> wrote:
>>      > §5.8:
>>
>>      >> Rather than returning the audit log as a response to the POST (with a
>>      >> return code 200), the MASA MAY instead return a 201 ("Created")
>>      >> RESTful response ([RFC7231] section 7.1) containing a URL to the
>>      >> prepared (and easily cachable) audit response.
>>
>>      > The DISCUSS portion of my comment on this text is that it is unclear 
>> about how
>>      > the URL is to be returned. It can just as easily be interpreted as 
>> returning
>>      > it in a "Location" header field as it could as returning it in the 
>> response
>>      > body -- or maybe somewhere else entirely (e.g., a link relation).  
>> This
>>      > ambiguity will cause an interop issue. Please be explicit about 
>> precisely how
>>      > the value is conveyed.
>>
>> I see how this could be confusing.
>>
>>      > While not part of the DISCUSS, I also have a fairly serious comment 
>> on the
>>      > phrasing and citation of  "return a 201 ("Created") RESTful response
>>      > ([RFC7231] section 7.1)". Section 7.1 points to the top-level 
>> discussion of
>>      > Control Data header fields, rather than any general discussion of 
>> RESTful
>>      > responses.  It's worth noting that the term "RESTful" never appears 
>> in RFC
>>      > 7231, so it's really unclear what section this was attempting to 
>> target.
>>      > Perhaps 6.3.2?
>>
>> Yes, that's what we are trying to target.
>> I guess we also latched onto section 7.1.2 ("Location")
>>
>> Can you point me to another document that tries to specify the same thing.
>> If we shouldn't say we are trying to be RESTful, what should we say?
> 
> 
> "HTTP", but even that may be unnecessary in this case.
> 
> REST means... something. Exactly what depends on who you ask. In 
> practice, the least controversial thing to do is avoid the term; 

I am unbelievably happy to read that. I thought it was forbidden to be
an unbeliever in RESTfulness.

> and, if 
> you're trying to describe a specific quality (e.g., idempotence), say so 
> explicitly.

In the simplest possible terms, isn't the quality we require that
an operation has unambiguously succeeded or unambiguously failed?
But in fact, simply deleting the two occurrences of "RESTful"
seems appropriate.

    Brian

> 
> For this document, I don't think you really care much the purported 
> properties of REST -- by any definition -- and I suspect you don't 
> conform to them, for at least some number of mutually incompatible and 
> religiously-held definitions of that term.
> 
> In any case, I don't think the reference adds anything to the text, 
> regardless of whether it points to 7.1.2 or to 6.3.2. So I would propose 
> something along the lines of:
> 

>     Rather than returning the audit log as a response to the POST (with 
> a 200
>     (OK) response code), the MASA MAY instead return a 201 (Created) 
> response
>     containing a "Location" header field that indicates the location of the
>     prepared audit response. This allows the audit response to appear at a
>     location that enables caching.
> 
> 
> If that says something other than what you meant, let me know, and I'll 
> try to fix it.
> 
> /a
> 
> _______________________________________________
> Anima mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/anima
> 

_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima

Reply via email to