<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
On May 6, 2015, at 1:58 PM, David Kranz <<a href="mailto:dkranz@redhat.com">dkranz@redhat.com</a>> wrote:<br>
<div><br class="Apple-interchange-newline">
<blockquote type="cite">
<div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">
+1<br>
The basic problem is we are trying to fit a square (generic api) peg in a round (HTTP request/response) hole.<br>
But if we do say we are recognizing "sub-error-codes", it might be good to actually give them numbers somewhere in the response (maybe an error code header) rather than relying on string matching to determine the real error. String matching is fragile and has
icky i18n implications.<br>
</div>
</blockquote>
<div><br>
</div>
<div>There is an effort underway around defining such "sub-error-codes” [1]. Those error codes would be surfaced in the REST API here [2]. Naturally feedback is welcome.</div>
<div><br>
</div>
<div>Everett</div>
<div><br>
</div>
<div><br>
</div>
<div>[1] <a href="https://review.openstack.org/#/c/167793/">https://review.openstack.org/#/c/167793/</a></div>
<div>[2] <a href="https://review.openstack.org/#/c/167793/">https://review.openstack.org/#/c/167793/</a></div>
</div>
</body>
</html>