- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Thu, 26 Mar 2020 01:42:28 +1300
- To: ietf-http-wg@w3.org
On 25/03/20 12:02 pm, Colm Divilly wrote: > Hi All, > for a product I help develop: Oracle REST Data Services (ORDS) [1], we > provide a hosted environment where third party users can dynamically at > runtime define their own REST APIs using SQL. Naturally there will be > coding and runtime errors in these REST APIs. > This creates a challenge > for users and operators. When such a resource raises an error the only > appropriate HTTP status code to use is 500 Internal Server Error. This > causes confusion as it looks like there is something wrong with ORDS, > where in fact there is only something wrong with the user supplied SQL. I see no guidance details about when this status is expected to be used, and the description given is lacking some important details: * Is this status used to reply to requests containing bad SQL? If yes, then use of any 5xx is incorrect. The broken thing being part of the client message means it should be a 4xx status of some type. If no; * Is the origin pre-configured with some SQL it failed to validate / wrongly accepted, which is now breaking responses? If yes, then 500 is indeed correct status. The "Internal Error" just happens to have been created by the SQL acceptance. Otherwise implies no SQL is known to the origin. So 404 would be appropriate. No such resource exists. Or, ... * Is the origin pre-configured with some SQL it has already accepted, but which does not produce a resource instance? If yes, then the status should be 404 or 406. The origin is not broken, it simply does not have any representation that meets the request. At the very least it would be good to describe what alternatives (other status, and other mechanisms) have been considered and why they are unworkable. PS. IIRC the number itself is supposed to be assigned by IANA *if* this document reaches acceptance. Not chosen by draft authors. Amos
Received on Wednesday, 25 March 2020 12:43:20 UTC