+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" <mrie...@linux.vnet.ibm.com> > To: "OpenStack Development Mailing List (not for usage questions)" > <openstack-dev@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@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 > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev