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?
