<div dir="ltr"><div>The downside of numbers rather than camel-case text is that they are less likely to stick in the memory of regular users. Not a huge think, but a reduction in usability, I think. On the other hand they might lead to less guessing about the error with insufficient info, I suppose.<br><br></div>To make the global registry easier, we can just use a per-service prefix, and then keep the error catalogue in the service code repo, pulling them into some sort of release periodically<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 3 February 2015 at 03:24, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">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>
</div></div>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>
<span class="HOEnZb"><font color="#888888"><br>
        -Sean<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
Sean Dague<br>
<a href="http://dague.net" target="_blank">http://dague.net</a><br>
<br>
</div></div><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><br><br clear="all"><br>-- <br><div class="gmail_signature">Duncan Thomas</div>
</div>