[openstack-dev] [nova] Should PUT /os-services be idempotent?
soulxu at gmail.com
Wed Jul 12 02:29:21 UTC 2017
2017-07-12 9:18 GMT+08:00 Matt Riedemann <mriedemos at gmail.com>:
> I'm looking for some broader input on something being discussed in this
> This is collapsing the following APIs into a single API:
> * PUT /os-services/enable
> * PUT /os-services/disable
> * PUT /os-services/disable-log-reason
> * PUT /os-services/force-down
> * PUT /os-services
> With the old APIs, if you tried to enable and already enabled service, it
> was not an error. The same is you tried to disable an already disabled
> service. It doesn't change anything, but it's not an error.
> The question is coming up in the new API if trying to enable an enabled
> service should be a 400, or trying to disable a disabled service. The way I
> wrote the new API, those are no 400 conditions. They don't do anything,
> like before, but they aren't errors.
Sorry, I didn't describe clearly in the comment.
Some of those comments about save a DB call with more conditions checks. It
means if enable a enabled service, we needn't a db call, we can just return
to the user 200 directly.
One of those comments is about when the API user specified 'status=enabled'
and 'disabled_reason' in the request body, then we just ignore the
'disabled_reason' and didn't save it into the db also. That sounds not
right. We should return 400 to the API user, you can't specified the
'status=enabled' and 'disabled_reason'.
> Looking at  it seems this should not be an error condition if you're
> trying to update the state of a resource and it's already at that state.
> I don't have a PhD in REST though so would like broader discussion on this.
>  http://www.restapitutorial.com/lessons/idempotency.html
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev