couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Gaul (JIRA) <>
Subject [jira] [Created] (COUCHDB-2396) Provide ?changes=true for all GET requests
Date Mon, 20 Oct 2014 10:27:34 GMT
André Gaul created COUCHDB-2396:

             Summary: Provide ?changes=true for all GET requests
                 Key: COUCHDB-2396
             Project: CouchDB
          Issue Type: Wish
      Security Level: public (Regular issues)
          Components: HTTP Interface
            Reporter: André Gaul

h2. Situation

Assume you've made one of the following HTTP requests against a CouchDB:

* GET /albums/foobar
* GET /albums/_design/ddoc/_view/by_name?startkey=foo

In a lot of applications, you're interested in the changes that happened since the last request
or you even want to receive continuous/live updates (e.g., via [Server Sent Events|]).
Actually, that's what CouchDB's _changes feed is made for (and it does a good job in a few
projects I maintain). CouchDB 2.0 seems to go a step further by providing a changes feed for
views (according to a discussion with [~janl] on irc, see also [here|]).
However, the _changes feed is a bit hard to use if you want to get the changes for a specific
request with all involved parameters (e.g., for the above view query).

h2. Improvement

>From a user's perspective, it would be much simpler if the changes could be fetched for
a specific request by simply appending _?changes=true_ and a _since_ parameter whose value
was provided by the previous request, e.g. by

* GET /albums/foobar?changes=true&since=4711
* GET /albums/_design/ddoc/_view/by_name?startkey=foo&changes=true&since=4711

Technically, the changes reply could consist of [JSON patches|].

This kind of _changes_ feature would be great for all REST APIs in the context of (near-)
real time apps. CouchDB probably has almost everything in place to support this feature and
make life much easier ;). On the other hand, I can imagine that it requires a significant
amount of work in CouchDB's internals.

Since I'm not too familiar with CouchDB's internals, I'd like to bring this idea up for discussion

This message was sent by Atlassian JIRA

View raw message