202 status on "DELETE /db"
--------------------------
Key: COUCHDB-1020
URL: https://issues.apache.org/jira/browse/COUCHDB-1020
Project: CouchDB
Issue Type: Improvement
Components: HTTP Interface
Affects Versions: 1.2
Reporter: Benoit Chesneau
Priority: Minor
Fix For: 1.2
Current status is 200 . Following irc discussion there are 2 points of you
considering tthat sicne db isn't accessible from HTTP api, 200 is ok.
But still data is on the disk and effectively, deletion is asynchronous. HTTP
Spec on DELETE :
[[[
A successful response SHOULD be 200 (OK) if the response includes an entity
describing the status, 202 (Accepted) if the action has not yet been enacted,
or 204 (No Content) if the action has been enacted but the response does not
include an entity.
]]]
and status 202 :
[[[
The request has been accepted for processing, but the processing has not been
completed. The request might or might not eventually be acted upon, as it might
be disallowed when processing actually takes place. There is no facility for
re-sending a status code from an asynchronous operation such as this.
The 202 response is intentionally non-committal. Its purpose is to allow a
server to accept a request for some other process (perhaps a batch-oriented
process that is only run once per day) without requiring that the user agent's
connection to the server persist until the process is completed. The entity
returned with this response SHOULD include an indication of the request's
current status and either a pointer to a status monitor or some estimate of
when the user can expect the request to be fulfilled.
]]]
Since it's true that deletion introduce an aysnchronous process to delete the
db file an it's data, I think that 202 is more appropriate here.
202 would mean, that resource isn't available but deletion is running. Related
to #COUCHDB-1019 we could pass a pid or taskid to the response eventually.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
