couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Young (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-2052) Add API for discovering feature availability
Date Thu, 06 Feb 2014 15:50:11 GMT


Benjamin Young commented on COUCHDB-2052:

There's a lot of work being done in the Hypermedia API world around just this issue. The response
can carry that information in a less-meta way by using good ole hyperlinks. :)

There are several options here (and it's a growing list):
* Hypermedia Application Layer (HAL) -
* Hydra -
* Collection+JSON -

More general info:

Using Hypermedia is far more resilient than using "magic strings" that a human has to look
up and hard code meaning for into their client-code...which is what we do now. Using a known
Hypermedia format (there are loads more than those 3 JSON-focused ones), provide a shared
foundation and community that can grow collectively, CouchDB (and friends) can all participate,
and we get a wider set of tools, developers, conferences, etc interested in our API...or that's
the idea. ;)

Thanks for bringing this up in any case, Jens!

> Add API for discovering feature availability
> --------------------------------------------
>                 Key: COUCHDB-2052
>                 URL:
>             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

View raw message