On Mar 28, 2012, at 9:16 AM, Jonathan Lundell wrote: > On Mar 28, 2012, at 8:15 AM, Anthony wrote: >> If you want to build a single-page app, you might also consider options like >> AngularJS (supported by Google) and batman.js (by Shopify). They move >> templating to the client, so your server just delivers the initial "page" >> (i.e., the whole app, including JS templates) and then takes Ajax requests >> and returns JSON rather than HTML. > > This relates to another all-json API, namely a JSON (possibly but not > necessarily JSON-RPC) web service. I use that to serve several iOS apps, and > it works nicely. There's one problem, though: errors. > > If an error occurs before the web2py JSON function is called (typically a 500 > error, such as a Python syntax error in the controller), web2py returns an > HTML response, and that's awkward for a JSON client to try to handle. > > One thing that slightly complicates matters is that to fix this, web2py would > need to know that a JSON or JSON-RPC (or for that matter XML-RPC or various > other formats) request has been made. For most/all 500 errors, we haven't > gotten to the @service decorator, so we ought to be looking at the requested > extension or the Accept: header. application/json is what should be there; > there's no distinction made for JSON-RPC, which is slightly awkward, but > suggests that we should just return a JSON-RPC error object, perhaps based on > the content of the request if it parses as JSON. > > One thing that's stopped me from proposing a patch is that this really ought > to be generalized for other non-html services, and perhaps be user-extensible > (though not necessarily through an application, since we might not have > access to the application at error time; maybe something in routes.py?). But > the perfect need not be the enemy of the good-enough, I suppose. > > Any interest in working out a definition for this?
Oh, and while we're at it (I'm reminded by Richard's last post): not just error handling, but a JSON/JSON-RPC interface to Auth.
