Joe Gregorio wrote:
>[snip]
> Actually, in the test code there are three levels: errors, warnings and
> suggestions. Errors are reserved for MUST level violations, warnings
> for SHOULD level violations and warnings are for things you really ought
> to do. Cache validators and compression are currently suggestions.
>
Ah, ok, overlooked that.
>[snip]
>> * When an entry is successfully created the server MUST return an HTTP
>> status code of 201.
>>
>> I'm fine with this, but the spec doesn't say "MUST". should it?
>
> Hard to tell, the current wording is:
>
> ""If the Member resource was created successfully,
> the server responds with a status code of 201""
>
> Are other status codes ok? I think this is ambiguous.
>
I don't see it as ambiguous. That is, it doesn't say you MUST use 201.
My interpretation of this is that the server can (and probably should)
respond with a 201, but other codes are possible.
>[snip]
>> * When an entry is successfully deleted the status code MUST be 200.
>>
>> The spec doesn't dictate a response for this. In fact, given that the
>> response payload is likely going to be empty, 204 would likely be more
>> appropriate and is the response code we currently return in our impl.
>> Regardless, any of the 2xx responses, or even a 3xx response could be
>> appropriate.
>
> Now updated to only report an error if the deletion failed (status
> code >= 400).
>
Good, thx.
>
>> * When an entry is successfully deleted it must be removed from the
>> associated feed.
>>
>> I'm fine with this, but this isn't actually ever stated in the spec.
>> Change it to a should and I'd be happier.
>
> So you believe we need more spec text here?
>
Possibly, but I'm not completely sure. Given that the feed returned to
the user may be filtered based on that users read permissions, I'm not
sure if this can be reliably tested. Further, if paging is used, you'd
end up having to walk the entire feed in order to verify that it had
actually been removed. In any case, I'm fine with the behavior, and
this is what we've implemented, but I'm not sure how to test or what
should be said about this in the spec (if anything)
- James
