user5116: I've been working on a project involving use of the various Blockchain.info APIs (specifically  the Blockchain Data API), and am wondering if anyone has tips regarding error handling: the API documentation says nothing about how errors are handled, and my experiments seem to indicate that errors are returned with HTTP status 200 and a strictly HTML response.
Has anyone implemented a client for this API and can shed some light on whether this is the "usual" state of affairs or a bug? Any additional tips would be greatly appreciated.

user-1: Error handling is not particularly well done. If you are specifying format=json errors should respond with status 500 and a text/plain message. But there may be errors HTML based errors as well.
If the response is not JSON parsable then it should be considered the server has encountered a generic error.

user5116: I ended up implementing a response handler that implements the following heuristic:

If status code is 200 and Content-Type header is "application/json" (with or without charset), the response is valid.
If the status code is 200 or 500 (I've observed both) and the Content-Type header is "text/html" (with or without charset), the response is erroneous and the error message may be extracted with the following regular expression: (?s).*<div.*?class="alert alert-error">.*?<h4>(.*?)</h4>.*.
Otherwise the response is erroneous but the specific error message cannot be extracted.

This seems to work well in practice.

5116: <p>I've been working on a project involving use of the various Blockchain.info APIs (specifically  the <a href="https://blockchain.info/api/blockchain_api" rel="nofollow">Blockchain Data API</a>), and am wondering if anyone has tips regarding error handling: the API documentation says nothing about how errors are handled, and my experiments seem to indicate that errors are returned with HTTP status 200 and a strictly HTML response.</p>

<p>Has anyone implemented a client for this API and can shed some light on whether this is the "usual" state of affairs or a bug? Any additional tips would be greatly appreciated.</p>
 -1: <p>Error handling is not particularly well done. If you are specifying format=json errors should respond with status 500 and a text/plain message. But there may be errors HTML based errors as well.</p>

<p>If the response is not JSON parsable then it should be considered the server has encountered a generic error.</p>
 5116: <p>I ended up implementing a response handler that implements the following heuristic:</p>

<ul>
<li>If status code is 200 and Content-Type header is "application/json" (with or without charset), the response is valid.</li>
<li>If the status code is 200 or 500 (I've observed both) and the Content-Type header is "text/html" (with or without charset), the response is erroneous and the error message may be extracted with the following regular expression: <code>(?s).*&lt;div.*?class="alert alert-error"&gt;.*?&lt;h4&gt;(.*?)&lt;/h4&gt;.*</code>.</li>
<li>Otherwise the response is erroneous but the specific error message cannot be extracted.</li>
</ul>

<p>This seems to work well in practice.</p>
