[ https://issues.apache.org/jira/browse/COUCHDB-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894405#comment-13894405 ]
Benoit Chesneau commented on COUCHDB-2052: ------------------------------------------ rather than API discovery I would prefer to describe capabilities. If we take the example of the replication for example, it seems that couchlite can use _bulk_get on the couchbase sync gateway or _changes and other things on couchdb. But some servers like the coming release of rcouch can handle both (ie proposing the _bulk_get feature). In the smpt world it would be represented as 2 capabilities corresponding to 2 well defined api/protocols. Here why not something like REPCOUCHDB01 and REPCOUCHBASE01 . whatever. A capability would then describe a behaviour and an entry point depending on the transport (http by default). Describing an expected behaviour is a way easier imo than expecting that all applications are able to parse a message in time etc. Also it would allows to define a default behaviour eventually. Then we could have a behaviour/protocol per type of actions: - Document api - Replication ... In term of implementation, when using the HTTP protocol why not getting them by issuing an OPTIONS method to / ? > Add API for discovering feature availability > -------------------------------------------- > > Key: COUCHDB-2052 > URL: https://issues.apache.org/jira/browse/COUCHDB-2052 > Project: CouchDB > Issue Type: Improvement > Security Level: public(Regular issues) > Components: HTTP Interface > Reporter: Jens Alfke > > I propose adding to the response of "GET /" a property called "features" or > "extensions" whose value is an array of strings, each string being an > agreed-upon identifier of a specific optional feature. For example: > {"couchdb": "welcome", "features": ["_bulk_get", "persona"]}, "vendor": > … > Rationale: > Features are being added to CouchDB over time, plug-ins may add features, and > there are compatible servers that may have nonstandard features (like > _bulk_get). But there isn't a clear way for a client (which might be another > server's replicator) to determine what features a server has. Currently a > client looking at the response of a GET / has to figure out what server and > version thereof it's talking to, and then has to consult hardcoded knowledge > that version X of server Y supports feature Z. > (True, you can often get away without needing to check, by assuming a feature > exists but falling back to standard behavior if you get an error. But not all > features may be so easy to detect — the behavior of an unaware server might > be to ignore the feature and do the wrong thing, rather than returning an > error — and anyway this adds extra round-trips that slow down the operation.) -- This message was sent by Atlassian JIRA (v6.1.5#6160)