DELETE routes return HTTP 204 even if the item doesn't exist

Bug #1596935 reported by Domhnall Walsh
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Backup/Restore and DR (Freezer)
Fix Released
Medium
Vishakha Agarwal

Bug Description

If we try to DELETE a non-existent item (action, session, backup, job or client), then the API returns a HTTP 204 (No Content) whether the item exists or not. If it does not exist, the API *should* return a HTTP 404 (Not Found) instead.

Changed in freezer:
assignee: nobody → Domhnall Walsh (domhnall-walsh)
Revision history for this message
Jeremy Liu (liujiong) wrote :

I suppose not. HTTP methods(get/delete/put) have idempotence feature.
When you retrive a non-existent object, a 404 error code should be returned, but if you delete a non-existent object, a 204 code should be fine.

Revision history for this message
Domhnall Walsh (domhnall-walsh) wrote :

I don't think I agree with this. My interpretation of https://specs.openstack.org/openstack/api-wg/guidelines/http.html and https://tools.ietf.org/html/rfc7231.html#section-6.5.4 leads me to think that as long as the identifier for the item is expressed as part of the URI (rather than in the request body) - as is the case here - then it should return a 404 if the resource doesn't exist.

Yes, DELETE is idempotent, you can call it as many times as you like and the state of the system afterwards will be the same. The status code it returns is a basically a side effect of the operation - whether it's 404 or 204, there is still no item with that id after the request as it's either deleted or wasn't there to begin with, but at the end of the day knowing that it was deleted or not is still important.

All else aside, I prefer to know that something doesn't exist if I try to perform an operation on it, even if that operation is DELETE. If a consumer of the API chooses to ignore that the item didn't exist and carry on, fine, but the API should at least provide the information and let the consumer decide. IMHO of course :)

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to freezer-api (master)

Fix proposed to branch: master
Review: https://review.openstack.org/337077

Changed in freezer:
status: New → In Progress
Changed in freezer:
importance: Undecided → Medium
Revision history for this message
Domhnall Walsh (domhnall-walsh) wrote :

This may have to wait until the next version of the API, because it does change its behaviour slightly.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on freezer-api (master)

Change abandoned by Saad Zaher (<email address hidden>) on branch: master
Review: https://review.openstack.org/337077
Reason: very old change, not valid any more

Changed in freezer:
assignee: Domhnall Walsh (domhnall-walsh) → Vishakha Agarwal (vishakha.agarwal)
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to freezer-api (master)

Fix proposed to branch: master
Review: https://review.openstack.org/564456

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to freezer-api (master)

Reviewed: https://review.openstack.org/564456
Committed: https://git.openstack.org/cgit/openstack/freezer-api/commit/?id=a4a68b3936cdb8b5daf2af319108e3927569ca1a
Submitter: Zuul
Branch: master

commit a4a68b3936cdb8b5daf2af319108e3927569ca1a
Author: Vishakha Agarwal <email address hidden>
Date: Thu Apr 26 16:07:31 2018 +0530

    Delete request for non-existent ID will be 404.

    When trying to delete a non-existent backup, action,
    client, job, session it will raise exception with
    HTTP response 404.

    Change-Id: I06d7261f40e36e46c2743d531f5673907a7263a3
    Closes-Bug: #1596935

Changed in freezer:
status: In Progress → Fix Released
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix included in openstack/freezer-api 7.0.0

This issue was fixed in the openstack/freezer-api 7.0.0 release.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.