On Sat, Aug 18, 2012 at 5:45 AM, Nico Williams <n...@cryptonector.com>wrote:
> codes. But what's the problem with returning both, an HTTP status > code and an application-specific one in the response entity? Doing so > would leave you with a RESTful API and your clients can just ignore > the HTTP result codes. > It just happened to accidentally evolve to the current mechanism because my JSON-centric apps catch connection-level errors (HTTP codes) at a lower level than app errors (response envelope code), and handle them differently (app errors tend to give me more detailed info). It's just more flexible that way in my experience. Let's put it this way. To return 200 for a POST that actually failed > is very strange -- the response entity had better, at the very least, > not be cacheable if you'll do that. > i would hope that no POSTs are cacheable :/. If the HTTP POST itself succeeds then yes, the JSON API will return an HTTP 200. If the app-specific JSON logic goes sideways, then that's an app-level error and that is reported via the envelope. i understand the arguments for using non-200 codes here, but i fundamentally feel that mixing app/transport error codes is is "just wrong," at least for this reason: the current approach allows us to pipe in json from any source and send it to any destination with exactly the same error-reporting semantics. That cannot be done if the API is tied to HTTP result codes. i have demo code which uses the Rhino JS engine (implemented in Java) to pipe JSON data to/from the stdin/stdout of a local Fossil binary, but the details of that transport are hidden away from the JS client, who uses the app-level API (which lives on top of the swappable connection-level API). See ajax/i-test/*.* for the details. -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
