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. On Feb 3, 2015 9:28 AM, "Sean Dague" <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. > > 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 > > > __________________________________________________________________________ > 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 > >
__________________________________________________________________________ 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