| 2011-03-14 23:54:24 |
Martin Pool |
description |
affects launchpad
status triaged
importance low
tags api error-reporting
At the moment if an API call fails with, for example, a 503 or 500
oops, you get back a quite large page of html. It would be a bit more
useful to most clients if we instead sent either plain text or json
description of the problem (including the oops if any), or at least if
we made the html more easily machine-parsable by making it xhtml with
defined ids. But many clients will want to just print the failure,
and for them something short would be better.
|
At the moment if an API call fails with, for example, a 503 or 500
oops, you get back a quite large page of html. It is hard for client programs to do anything with this except dump it to the screen which is ugly. As a result many API failures do not have a visible oops, which makes it harder for the client to know what the problem is, or to give feedback to the Launchpad developers.
Launchpad apparently sends back an X-Lazr-OopsID on some (most?) failed requests. If this was parsed out and put into a structured field then clients could eg show a short message to the user about the failure, or accumulate a list of requests that failed and their corresponding oopses.
(Separately, it might be nice if the response to failed api requests was a json description of the problem, not html, but that's less important. It does not need to be a fine-grained description: just a dict pointing to the oops id, traceback, etc would be enough.) |
|
