<p dir="ltr">Agree with Sean. A short error name in response body would be better for applications who consume OpenStack. To my understand, the X-OpenStack-Error-Help-URI proposed by jpipes will be a uri to error resolution method. Usually, a consumer application needn't to load its content.</p>
<div class="gmail_quote">On Feb 3, 2015 9:28 AM, "Sean Dague" <<a href="mailto:sean@dague.net">sean@dague.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 02/02/2015 05:35 PM, Jay Pipes wrote:<br>
> On 01/29/2015 12:41 PM, Sean Dague wrote:<br>
>> 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>
> <snip><br>
>><br>
>> Standardization here from the API WG would be really great.<br>
><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" target="_blank">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" target="_blank">errors.openstack.org</a>.<br>
<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>
<br>
The if we are going to having global codes that are just numbers, we'll<br>
also need a global naming registry. Which isn't a bad thing, just<br>
someone will need to allocate the numbers in a separate global repo<br>
across all projects.<br>
<br>
        -Sean<br>
<br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div>