ricellis commented on issue #1082: Provide info=true and keys=[] arguments for /_all_dbs URL: https://github.com/apache/couchdb/pull/1082#issuecomment-357691338 I wonder if accepting `keys` should only be part of a `POST` body. I think this has two advantages: i) It avoids the URL length limitations that we've seen previously with including long lists of keys in a URL. ii) It also avoids URL encoding work for the caller (although admittedly that is less of an issue with a DB name than with, for example, view keys). This would be consistent with `_all_docs` and `_view` which allow `POST` of a list of keys. Whilst those endpoints also support `keys` as a query parameter I think that is only for backwards compatibility - so for a new API accepting `POST` only for `keys` could make the most sense. IMO one of the pain points in using the CouchDB API in the past has been changes in the response schema for the same endpoint (based on e.g. a query parameter). It seems like this is proposing to introduce yet another example of this similar problem: `_all_dbs` -> `["db1", "db2"]` (list of strings) `_all_dbs?info=true` -> [{"key": "db1", "info": {...}}, {"key": "db2", "info": {...}}]` (list of objects) I think using a new endpoint e.g. `_all_dbs_info` (or whatever) makes a more usable API because it can be made clear that the returned schema is different than that used for `_all_dbs`. Further, given that it appears this operation isn't even going to be allowed for cases where there are more than 100 DBs, then something like `_dbs_info` makes more sense as a name than `_all_dbs` (since it isn't necessarily going to be all the DBs). Combining the above with the concern that this should probably be limited to avoid retrieving metadata for all the DBs at once under most circumstances then perhaps a more intuitive API would be one that only accepts a list of keys e.g.: `POST` `_dbs_info` `{"keys" : ["dbName1", "dbName2"]}`
---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected] With regards, Apache Git Services
