Open Stack

On 02/02/2015 05:35 PM, Jay Pipes wrote:
> On 01/29/2015 12:41 PM, Sean Dague wrote:
>> Correct. This actually came up at the Nova mid cycle in a side
>> conversation with Ironic and Neutron folks.
>>
>> HTTP error codes are not sufficiently granular to describe what happens
>> when a REST service goes wrong, especially if it goes wrong in a way
>> that would let the client do something other than blindly try the same
>> request, or fail.
>>
>> Having a standard json error payload would be really nice.
>>
>> {
>>       fault: ComputeFeatureUnsupportedOnInstanceType,
>>       messsage: "This compute feature is not supported on this kind of
>> instance type. If you need this feature please use a different instance
>> type. See your cloud provider for options."
>> }
>>
>> That would let us surface more specific errors.
> <snip>
>>
>> Standardization here from the API WG would be really great.
> 
> 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?
> 
> Something like:
> 
> X-OpenStack-Error-Code: 1234
> X-OpenStack-Error-Help-URI: http://errors.openstack.org/1234
> 
> 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 errors.openstack.org.

That could definitely be implemented in the short term, but if we're
talking about API WG long term evolution, I'm not sure why a standard
error payload body wouldn't be better.

The if we are going to having global codes that are just numbers, we'll
also need a global naming registry. Which isn't a bad thing, just
someone will need to allocate the numbers in a separate global repo
across all projects.

	-Sean

-- 
Sean Dague
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 465 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150202/90864306/attachment.pgp>