[ 
https://issues.apache.org/jira/browse/COUCHDB-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894698#comment-13894698
 ] 

Robert Newson commented on COUCHDB-2052:
----------------------------------------

Ok, so one value here is to optimize feature discovery rather than discovery 
itself. There was a time when it was the fashion to add HTTP Link headers 
(https://www.rfc-editor.org/rfc/rfc5988.txt, apparently) to aid browsers, but 
perhaps that idea, for "GET /", would work to enumerate endpoints of interest?


> 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)

Reply via email to