mikerhodes/deleted_dbs.md Secret

## deleted_dbs.md

      
    Raw
  

              deleted_dbs.md
            
          
    If we followed this train to it's conclusion (fully resource based, with use of _all_dbs responses).
The open question for me is whether the collection GET requests actually return something view-style, with key/value semantics, and what that looks like (what is the value?).
Get all deleted databases

GET /_deleted_dbs
Response:

200 OK; ["airportdb","animaldb"]
500

Optionally mirroring _all_dbs:
GET /_deleted_dbs?key="animaldb"
Response:

200 OK; ["animaldb"]
500

Get all "versions" of a deleted database

GET /_deleted_dbs/DbName
Response:

200 OK; ["2020-01-01T00:00:00","2020-01-01T14:14:14"]
404 Not Found
500

Get some metadata of a deleted database (because it's potentially useful)

GET /_deleted_dbs/DbName/2020-01-01T00:00:00
Response:

200 OK; {"ts": "2020-01-01T00:00:00"} (just to return something I couldn't figure something better)
404 Not Found
500

Delete a particular version of a deleted database

DELETE /_deleted_dbs/DbName/2020-01-01T00:00:00
Response:

200 OK; {"ok": true}
404 Not Found
500; {"ok": false, "reason": "foodles"} (or whatever our standard error body is)

Question: do we want DELETE /_deleted_dbs/DbName to delete all copies? My inclindation is "no".
Undelete a particular version of a deleted database

By default to the original location, with optional target param in body.
POST /_deleted_dbs/DbName/2020-01-01T00:00:00; body {"action": "undelete"} (optional "target" in body for restore to a different database?)
Response:

200 OK; {"ok": true, "dbname": "DbName"}
404 Not Found
500; {"ok": false, "reason": "foodles"} (or whatever our standard error body is)