Changes (60)

{note:title=Open Questions} * Expose documents and views APIs through the same HTTP socket. ** Let people operate on two endpoints separately and optionally map them to the endpoints they want. It will be the most natural way with nginx, where everything built around {{location}} entity. ** Develop some standard schema prefixes like {{_doc/}} and {{_design}}, to allow to reference them, but here is another question "do we need to inject prefix in all places, like view results?" * Represent document keys so that they could be passed in URI. Urlencoding is quite common, but in views the server is using base64 * Unlike memcache protocol, it should also encode bodies of the documents somehow, therefore MIME support. How we should do it? * _low priority_ Evaluate what we need to support CouchApp-like deployment: ** authentication and authorization! ** proxy to syncgateway instead to raw couchbase? ** new API to store attachments somewhere ** additional useful APIs, like lists (can be done with multi-get) {note}

* auth scheme, on this step you might only protect your API endpoint using nginx built-in means * expiration handling. in Couchbase database it is possible to associate with the key expiration time. This feature will be exposed later

There are several terms we are using while describing this API.

|| Term || Definition||

| mount point | The part of URI which where couchbase nginx module connected |

| document | | Arbitrary JSON or BLOB value. It could be referenced by its ID |

| bucket | The logical storage, which contains the documents. Like *database* in SQL world, or *collection* in mongodb |

Lets assume we have a bucket named {{wonderland}}.

h2. Configuration and URIs

The Couchbase API could be mount to any endpoint in your application, and during configuration the bucket name and credentials should be specified like this:

The config section above tell nginx to use {{/wonderland/}} mount point to expose Couchbase API.

By default only Document API will be mounted, i.e. only CRUD operations can be executed there. Because in Couchbase itself both Document and Views APIs lives in completely different namespaces, the nginx module also keeps them separate. The example below will mount views and the documents into the common root.

The snippet above will translate this URI {{/storage/foo?cmd=replace&exptime=40}} to the {{replace "foo" ...}} command with expiration of 40 seconds. In the same way can be controller ID, value, flags and expiration time.

The rest of the section demonstrates various example of usage the API, including optimistic locking with CAS. It assumes the following config:

You can also specify ID with POST request if you need to *create* the document with given ID. {code:none} POST /wonderland/alice > Content-Type: application/json

{"name":"Alice","species":"human"} < 201

< ETag: "f5b8da2cf1570000"10952782243130507265

< Location: http://couchbasenginx.apiary.io/wonderland/alice {code}

...

Note that when you are using POST request, the server is always supposed to create the new document. This means that you will get an error if the document already exists. {code:none} POST /wonderland/foobar > Content-Type: application/json {"foo":"bar"} < 409 < Content-Type: application/json < Content-Length: 74 {"error":"key_eexists","reason":"Key exists (with a different ETag value)"} {code}

In case when the given document ID isn't exist in the bucket you will get *404 Not Found* {code:none} GET /wonderland/red-queen < 404 < Content-Type: application/json < Content-Length: 45 {"error":"key_enoent","reason":"No such key"}

{code}

Use *HEAD* request to skip the document body HEAD /wonderland/gryphon

{code:none}

HEAD /wonderland/gryphon

< 200 < Content-Type: application/json

< ETag: "55c3a92df1570000"10952782243130507269

{code}

...

Each operation is carry ETag, which internally is CAS value. The ETag value can be used in the conditional requests with *If-Match*, *If-None-Match*. See examples of *If-Match* above.

Check if the key has been modified (in this case the server responds that it wasn't modified):

{code:none} HEAD /wonderland/dormouse

> If-None-Match: "3f5b792df1570000"

< If-None-Match: 10952782243130507269

< 304 {code}

h2. Couchbase Views

...

This section shows more advanced server feature: View indexes

One of the features of the Couchbase is ability to build efficient indexes leveraging Map/Reduce. They are called Views and you can define them on Admin Console UI.

ThisThe module allows you to query your views proxying them to Couchbase. All arguments will be transparently passed to Couchbase and the result will be streamed back.