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.
<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<http://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.
Everett
[1] https://tools.ietf.org/html/rfc6648
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
