Open Stack

+1 on this sentiment.

>From the perspective of the client, I typically imagine a web browser. A 404 means that a "thing was not found" and this **implies** that I might specify a different "thing" so that I do *not* get a 404. But in many of the circumstances the 404 root cause is a server-side misconfiguration or some other fault I'll need to grab a different access mechanism to get at. That's decidedly *not* something I can do anything about from my hypothetical "web browser".

# Shawn Hartsock


----- Original Message -----
> From: "Matt Riedemann" <mriedem at linux.vnet.ibm.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Sent: Monday, November 25, 2013 3:57:40 PM
> Subject: [openstack-dev] [nova] Should the server create API return 404	errors?
> 
> Aaron Rosen is working a patch [1] to handle a NetworkNotFound exception
> in the server create API.  For the V2 API this will return a 400 error.
>   For the V3 API this will return a 404 because of a V3-specific patch
> [2].  The API docs list 404 as a valid response code, but is it
> intuitive for a POST request like this?
> 
> To muddy the waters more, ImageNotFound, FlavorNotFound and
> KeypairNotFound are translated to 400 errors in both the V2 and V3 APIs.
> 
> So why should the network-specific NotFound exceptions be a 404 but the
> others aren't?
> 
>  From a programmatic perspective, I should validate that my request
> parameters are valid before calling the API in order to avoid a 404.
>  From a user's perspective, a 404 seems strange - does it mean that the
> server I'm trying to create isn't found?  No, that's counter-intuitive.
> 
> Ultimately I think we should be consistent, so if 404 is OK, then I
> think the V3 API should make ImageNotFound, FlavorNotFound and
> KeypairNotFound return a 404 also.
> 
> Thoughts?
> 
> [1]
> https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%23/c/54202/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=U9jd8i1QXRWQEdLI1XfrWPjXsJaoGrk8w31ffdfY7Wk%3D%0A&m=7rsVb0MXXnUjVL99Tv59k6aBr4vECecgzzAPtcPTm1s%3D%0A&s=04c6373178135ef5df18bd52ef74d80327b65d29029be1131297dd2fb48cae1e
> [2]
> https://urldefense.proofpoint.com/v1/url?u=https://review.openstack.org/%23/c/41863/&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=U9jd8i1QXRWQEdLI1XfrWPjXsJaoGrk8w31ffdfY7Wk%3D%0A&m=7rsVb0MXXnUjVL99Tv59k6aBr4vECecgzzAPtcPTm1s%3D%0A&s=65c546e11e8ed9c82993d55d2316d3c981a5e7eed461cb98d04d26aa7a89ddcb
> 
> --
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=U9jd8i1QXRWQEdLI1XfrWPjXsJaoGrk8w31ffdfY7Wk%3D%0A&m=7rsVb0MXXnUjVL99Tv59k6aBr4vECecgzzAPtcPTm1s%3D%0A&s=2c79105a20f5ca91f32b0b2b82cd7d82a7b3c277480831371724b1674c9a3363
>