On 02/02/2015 09:07 PM, Everett Toews wrote:
On Feb 2, 2015, at 7:24 PM, Sean Dague <s...@dague.net
<mailto:s...@dague.net>> wrote:

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.

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.

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.


[1] https://tools.ietf.org/html/rfc6648

Ha! Good to know about the X- stuff :) Duly noted!


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to