- From: Mark Baker <distobj@acm.org>
- Date: Mon, 4 Mar 2002 14:06:29 -0500 (EST)
- To: jacek@systinet.com (Jacek Kopecky)
- Cc: chris.ferris@sun.com (Christopher Ferris), skw@hplb.hpl.hp.com (Williams Stuart), xml-dist-app@w3.org
This is not a REST specific problem, it's specific to all non-tunnelled uses of an underlying protocol that distinguishes between "data" and "error" on responses (i.e. application protocols). For a real-life example of this, consider the difference between these two URIs. http://www.ibiblio.org/not-a-real-resource http://www.ibiblio.org/404 The former is not a real URI, and so it is returned with a 404 status code. The latter identifies what is returned when a resource is not found, but invoking GET on it returns the *same content* as a 404, but with a 200 response code, ensuring that the browser can bookmark it, cache it, etc.. Requiring that the content be different to indicate this difference in semantics seems like unnecessary bloat, especially when I thought we had already decided that reusing the fault semantics from the underlying protocol was a Good Thing (per our decision to not send faults over HTTP 200). While transport (not application) protocol bindings may need this, it isn't clear that there needs to be a standardized means of communicating it within the envelope for these protocols, especially when it will only complicate application protocol bindings. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com
Received on Monday, 4 March 2002 14:15:48 UTC