<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 3, 2015 at 9:05 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 01/29/2015 12:41 PM, Sean Dague wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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: ComputeFeatureUnsupportedOnIns<u></u>tanceType,<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></span>
<snip><span class=""><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Standardization here from the API WG would be really great.<br>
</blockquote>
<br></span>
What about having a separate HTTP header that indicates the "OpenStack Error Code", along with a generated URI for finding more information 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" target="_blank">http://errors.openstack.org/<u></u>1234</a><br>
<br>
That way is completely backwards compatible (since we wouldn't be changing response payloads) and we could handle i18n entirely via the HTTP help service running on <a href="http://errors.openstack.org" target="_blank">errors.openstack.org</a>.<br>
<br></blockquote><div><br></div><div>So I'm +1 to adding the X-OpenStack-Error-Code header assuming the error code is unique</div><div>across OpenStack APIs and it has a fixed meaning (we never change it, create a new one if</div><div>a project has a need for an error code which is close to the original one but a bit different)</div><div><br></div><div>The X-OpenStack-Error-Help-URI header I'm not sure about. We can't guarantee that apps will have</div><div>access to <a href="http://errors.openstack.org">errors.openstack.org</a> - is there an assumption here that we'd build/ship an error translation service?</div><div><br></div><div>Regards,</div><div><br></div><div>Chris</div></div></div></div>