yay_api.md

There are three operations we care about:

1. Show me all soft-deleted databases with associated metadata
2. Undelete a soft-deleted database
3. Actually delete a soft-deleted database

Show Soft Deleted Dbs

• GET /_deleted_dbs
• GET /_deleted_dbs_info (maybe for clarity?)
• GET /_dbs_info?deleted=true (fewer special paths?)

This is shaped like _dbs_info and has support for all of the standard view query string options (key, start/end key, limit, offset, etc).

Example response:

[
  {
    "info": {
        ...  db info blob ...
    },
    "key": "dbname",
    "timestamp": "2020-01-01T00:00:00"
  },
  ....
]

Undelete database

• POST /_deleted_dbs
• POST /_undelete_db
• PUT /DbName with the {"undelete": ...} body (fewer special paths)

If we do _deleted_dbs_info I'd be much less inclined for a POST _deleted_dbs_info version cause that's kinda weird.

When undelete isn't in the path I'd expect the body to include the top level "undelete" key.

Request bodies would be one of these depending on the path:

{
    "undelete": {
        "source": "source_dbname",
        "source_timestamp": "...",
        "target": "optional_target_dbname"
    }
}

{
    "source": "source_dbname",
    "source_timestamp": "...",
    "target": "optional_target_dbname"
}

Actually delete a soft-deleted database

DELETE /_deleted_dbs/DbName?timestamp=foo DELETE /DbName?timestamp=foo

Again, if we go with something that has "info" in the path I'd move away from that has handling actual deletion.