On Jul 5, 2006, at 11:02 PM, Joe Gregorio wrote:
On 7/5/06, Tim Bray <[EMAIL PROTECTED]> wrote:
On Jul 5, 2006, at 12:09 PM, Joe Gregorio wrote:
>> 2. Upon a successful update of the resource the server
>> responds with
>> a status code of 200.
>>
>> Would not a 204 No Content be appropriate as well given that we're
>> not
>> requiring or recommending the update to return a response?
>
> Agreed.
-1
I would be irritated at a server that did this.
Isn't an Atom client inherently also an HTTP client - and shouldn't
an HTTP client understand (expect and handle) all HTTP status codes?
If there's no bloody
response I can bloody tell there's no bloody response, why does the
server have to tell me again? The existing language "responds with a
status code of 200" is simple and unambiguous and clear and
implementor-friendly; why fuzzify it? -Tim
A server can return a 401, a 301, etc. There are lots of perfectly
useful
HTTP status codes a server could return, the spec text gives the
impression
that only a 200 is acceptable, but that's not true and the wording
needs to be fixed to avoid that misperception.
Agreed. IMHO, if the spec intends to make proper use of HTTP (IOW
adhere to REST principles) it *can* specify message semantics but it
*can not* constrain HTTP (e.g. by introducing a contract between
server and client that POST will only return certain status codes).
Or am I missing something?
Jan
-joe
--
Joe Gregorio http://bitworking.org
