<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 Feb 2, 2015, at 7:24 PM, Sean Dague <<a href="mailto:sean@dague.net">sean@dague.net</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;">
On 02/02/2015 05:35 PM, Jay Pipes wrote:<br>
<blockquote type="cite">On 01/29/2015 12:41 PM, Sean Dague wrote:<br>
<blockquote type="cite">Correct. This actually came up at the Nova mid cycle in a side<br>
conversation with Ironic and Neutron folks.<br>
<br>
HTTP error codes are not sufficiently granular to describe what happens<br>
when a REST service goes wrong, especially if it goes wrong in a way<br>
that would let the client do something other than blindly try the same<br>
request, or fail.<br>
<br>
Having a standard json error payload would be really nice.<br>
<br>
{<br>
fault: ComputeFeatureUnsupportedOnInstanceType,<br>
messsage: "This compute feature is not supported on this kind of<br>
instance type. If you need this feature please use a different instance<br>
type. See your cloud provider for options."<br>
}<br>
<br>
That would let us surface more specific errors.<br>
</blockquote>
<snip><br>
<blockquote type="cite"><br>
Standardization here from the API WG would be really great.<br>
</blockquote>
<br>
What about having a separate HTTP header that indicates the "OpenStack<br>
Error Code", along with a generated URI for finding more information<br>
about the error?<br>
<br>
Something like:<br>
<br>
X-OpenStack-Error-Code: 1234<br>
X-OpenStack-Error-Help-URI: <a href="http://errors.openstack.org/1234">http://errors.openstack.org/1234</a><br>
<br>
That way is completely backwards compatible (since we wouldn't be<br>
changing response payloads) and we could handle i18n entirely via the<br>
HTTP help service running on <a href="http://errors.openstack.org">errors.openstack.org</a>.<br>
</blockquote>
<br>
That could definitely be implemented in the short term, but if we're<br>
talking about API WG long term evolution, I'm not sure why a standard<br>
error payload body wouldn't be better.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Agreed. And using the “X-“ prefix in headers has been deprecated for over 2 years now [1]. I don’t think we should be using it for new things. </div>
<div><br>
</div>
<div>Everett</div>
<div><br>
</div>
<div>[1] <a href="https://tools.ietf.org/html/rfc6648">https://tools.ietf.org/html/rfc6648</a></div>
</div>
<br>
</body>
</html>