[ https://issues.apache.org/jira/browse/COUCHDB-2052?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13894629#comment-13894629 ]
Benoit Chesneau commented on COUCHDB-2052:
------------------------------------------
[~snej] afaik definiing entrypoint and their use or not is about protocol. Saying I can use _bulk_get is a capability. defining it is available for the replication is a protocol.
About using Options, well this what we already use for CORS which far more than checking available methods.
[~bigbluehat] Hypermedia is fine, but a little to much oriented URI. I wonder how it could work on non HTTP protocols.
About channels and co, I am afraid we are mixing 2 issues, ie metadata added by channels, and defined by the channel spec or protocol, and the way we want to advertise the capabilities of a node.
In fact I am thinking that this story of "API" is misleading, I would prefer to speak about resources and the capabilities of a node to accept them or not (REST). URI are a way to see these resources but not only. Concretely a Couchdb node actually exposes the following resources
database
document
replication
stat
...
on which you can access over http, can bulk get ...
- benoit
> 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)