CouchDB 1.1 Manual

+ + CouchDB 1.1 Manual + + + + + + + This manual documents the CouchDB + 1.1 database system, including the installation, + functionality, and CouchDB API. + + + + Last document update: 21 Feb 2012 20:09; + Document built: 21 Feb 2012 20:9. + + + + + + + + + Introduction + + + There are two interfaces to CouchDB, the built-in + Futon web-based interface and the CouchDB API accessed through the + HTTP REST interface. The former is the simplest way to view and + monitor your CouchDB installation and perform a + number of basic database and system operations. More information on + using the Futon interface can be found in + . + + + + The primary way to interact with the CouchDB API is to use a client + library or other interface that provides access to the underlying + functionality through your chosen language or platform. However, + since the API is supported through HTTP REST, you can interact with + your CouchDB with any solution that supports the + HTTP protocol. + + + + There are a number of different tools that talk the HTTP protocol + and allow you to set and configure the necessary information. One + tool for this that allows for access from the command-line is + curl. See + . + + +

+ + Using Futon + + + Futon is a native web-based interface built into CouchDB. It provides a basic interface to the majority of the + functionality, including the ability to create, update, delete and + view documents and views, provides access to the configuration + parameters, and an interface for initiating replication. + + + + The default view is the Overview page which + provides you with a list of the databases. The basic structure of + the page is consistent regardless of the section you are in. The + main panel on the left provides the main interface to the + databases, configuration or replication systems. The side panel on + the right provides navigation to the main areas of Futon + interface: + + +

+ + Futon Overview + + + + + + + + + + + + Futon Overview + + + + + + + + + The main sections are: + + + + + + + Overview + + + + The main overview page, which provides a list of the databases + and provides the interface for querying the database and + creating and updating documents. See + . + + + + + + Configuration + + + + An interface into the configuration of your CouchDB installation. The interface allows you to edit the + different configurable parameters. For more details on + configuration, see + . + + + + + + Replicator + + + + An interface to the replication system, enabling you to + initiate replication between local and remote databases. See + . + + + + + + Status + + + + Displays a list of the running background tasks on the server. + Background tasks include view index building, compaction and + replication. The Status page is an + interface to the + Active + Tasks API call. See + . + + + + + + Verify Installation + + + + The Verify Installation allows you to + check whether all of the components of your CouchDB installation are correctly installed. + + + + + + Test Suite + + + + The Test Suite section allows you to + run the built-in test suite. This executes a number of test + routines entirely within your browser to test the API and + functionality of your CouchDB installation. If + you select this page, you can run the tests by using the + Run All button. This will execute all + the tests, which may take some time. + + + + + +

+ + Managing Databases and Documents + + + You can manage databases and documents within Futon using the + main Overview section of the Futon + interface. + + + + To create a new database, click the Create Database + … button. You will be prompted for the + database name, as shown in the figure below. + + +

+ + Creating a Database + + + + + + + + + + + + Creating a Database + + + + + + + + + Once you have created the database (or selected an existing + one), you will be shown a list of the current documents. If you + create a new document, or select an existing document, you will + be presented with the edit document display. + + + + Editing documents within Futon requires selecting the document + and then editing (and setting) the fields for the document + individually before saving the document back into the database. + + + + For example, the figure below shows the editor for a single + document, a newly created document with a single ID, the + document _id field. + + +

+ + Editing a Document + + + + + + + + + + + + Editing a Document + + + + + + + + + To add a field to the document: + + + + + + + Click Add Field. + + + + + + In the fieldname box, enter the name of the field you want + to create. For example, company. + + + + + + Click the green tick next to the field name to confirm the + field name change. + + + + + + Double-click the corresponding Value + cell. + + + + + + Enter a company name, for example Example. + + + + + + Click the green tick next to the field value to confirm the + field value. + + + + + + The document is still not saved as this point. You must + explicitly save the document by clicking the Save + Document button at the top of the page. This + will save the document, and then display the new document + with the saved revision information (the + _rev field). + + +

+ + Edited Document + + + + + + + + + + + + Edited Document + + + + + + + + + + + + The same basic interface is used for all editng operations + within Futon. You must rememmbr to save the + individual element (fieldname, value) using the green tick + button, before then saving the document. + + +

+ +

+ + Configuring Replication + + + When you click the Replicator option + within the Tools menu you are presented + with the Replicator screen. This allows you to start replication + between two databases by filling in or select the appropriate + options within the form provided. + + +

+ + Replication Form + + + + + + + + + + + + Replication Form + + + + + + + + + To start a replication process, either the select the local + database or enter a remote database name into the corresponding + areas of the form. Replication occurs from the database on the + left to the database on the right. + + + + If you are specifying a remote database name, you must specify + the full URL of the remote database (including the host, port + number and database name). If the remote instance requires + authentication, you can specify the username and password as + part of the URL, for example + http://username:pass@remotehost:5984/demo. + + + + To enable continuous replication, click the + Continuous checkbox. + + + + To start the replication process, click the + Replicate button. The replication process + should start and will continue in the background. If the + replication process will take a long time, you can monitor the + status of the replication using the + Status option under the + Tools menu. + + + + Once replication has been completed, the page will show the + information returned when the replication process completes by + the API. + + + + The Replicator tool is an interface to the + underlying replication API. For more information, see + . + For more information on replication, see + . + + +

+ +

+ + Using <command moreinfo="none">curl</command> + + + The curl utility is a command line tool + available on Unix, Linux, Mac OS X and Windows and many other + platforms. curl provides easy access to the + HTTP protocol (among others) directly from the command-line and is + therefore an ideal way of interacting with CouchDB + over the HTTP REST API. + + + + For simple GET requests you can supply the URL + of the request. For example, to get the database information: + + +shell> curl http://127.0.0.1:5984 + + + This returns the database information (formatted in the output + below for clarity): + + +{ + "modules" : { + "geocouch" : "7fd793c10f3aa667a1088a937398bc5b51472b7f" + }, + "couchdb" : "Welcome", + "version" : "1.1.0", +} + + + + For some URLs, especially those that include special characters + such as ampersand, exclamation mark, or question mark, you + should quote the URL you are specifying on the command line. For + example: + + +shell> curl 'http://couchdb:5984/_uuids?count=5' + + + + You can explicitly set the HTTP command using the + command line option. For example, when + creating a database, you set the name of the database in the URL + you send using a PUT request: + + +shell> curl -X PUT http://127.0.0.1:5984/demo +{"ok":true} + + + But to obtain the database information you use a + GET request (with the return information + formatted for clarity): + + +shell> curl -X GET http://127.0.0.1:5984/demo +{ + "compact_running" : false, + "doc_count" : 0, + "db_name" : "demo", + "purge_seq" : 0, + "committed_update_seq" : 0, + "doc_del_count" : 0, + "disk_format_version" : 5, + "update_seq" : 0, + "instance_start_time" : "1306421773496000", + "disk_size" : 79 +} + + + For certain operations, you must specify the content type of + request, which you do by specifying the + Content-Type header using the + command-line option: + + +shell> curl -H 'Content-type: application/json' http://127.0.0.1:5984/_uuids + + + You can also submit 'payload' data, that is, data in the body of + the HTTP request using the option. This is + useful if you need to submit JSON structures, for example document + data, as part of the request. For example, to submit a simple + document to the demo database: + + +shell> curl -H 'Content-type: application/json' \ + -X POST http://127.0.0.1:5984/demo \ + -d '{"company": "Example, Inc."}' +{"ok":true,"id":"8843faaf0b831d364278331bc3001bd8", + "rev":"1-33b9fbce46930280dab37d672bbc8bb9"} + + + In the above example, the argument after the + option is the JSON of the document we want to submit. + + + + The document can be accessed by using the automatically generated + document ID that was returned: + + +shell> curl -X GET http://127.0.0.1:5984/demo/8843faaf0b831d364278331bc3001bd8 +{"_id":"8843faaf0b831d364278331bc3001bd8", + "_rev":"1-33b9fbce46930280dab37d672bbc8bb9", + "company":"Example, Inc."} + + + The API samples in the show + the HTTP command, URL and any payload information that needs to be + submitted (and the expected return value). All of these examples + can be reproduced using curl with the + command-line examples shown above. + + +

+ + + + + + Features and Functionality + + + + + +

+ + HTTP Range Requests + + + HTTP allows you to specify byte ranges for requests. This allows + the implementation of resumable downloads and skippable audio and + video streams alike. The following example uses a text file to + make the range request process easier. + + +shell> cat file.txt +My hovercraft is full of eels! + + + Uploading this as an attachment to a text + database using curl: + + +shell> curl -X PUT http://127.0.0.1:5984/test/doc/file.txt \ + -H "Content-Type: application/octet-stream" -d@file.txt +{"ok":true,"id":"doc","rev":"1-287a28fa680ae0c7fb4729bf0c6e0cf2"} + + + Requesting the whole file works as normal: + + +shell> curl -X GET http://127.0.0.1:5984/test/doc/file.txt +My hovercraft is full of eels! + + + But to retrieve only the first 13 bytes using + curl: + + +shell> curl -X GET http://127.0.0.1:5984/test/doc/file.txt -H "Range: bytes=0-12" +My hovercraft + + + HTTP supports many ways to specify single and even multiple byte + rangers. See + RFC + 2616. + + + + + Databases that have been created with CouchDB 1.0.2 or earlier + will support range requests in 1.1.0, but they are using a + less-optimal algorithm. If you plan to make heavy use of this + feature, make sure to compact your database with CouchDB 1.1.0 + to take advantage of a better algorithm to find byte ranges. + + + +

+ +

+ + HTTP Proxying + + + The HTTP proxy feature makes it easy to map and redirect different + content through your CouchDB URL. The proxy works by mapping a + pathname and passing all content after that prefix through to the + configured proxy address. + + + + Configuration of the proxy redirect is handled through the + [httpd_global_handlers] section of the CouchDB + configuration file (typically local.ini). The + format is: + + +[httpd_global_handlers] +PREFIX = {couch_httpd_proxy, handle_proxy_req, <<"DESTINATION">>} + + + Where: + + + + + + + PREFIX + + + + Is the string that will be matched. The string can be any + valid qualifier, although to ensure that existing database + names are not overridden by a proxy configuration, you can use + an underscore prefix. + + + + + + DESTINATION + + + + The fully-qualified URL to which the request should be sent. + The destination must include the http + prefix. The content is used verbatim in the original request, + so you can also forward to servers on different ports and to + specific paths on the target host. + + + + + + + The proxy process then translates requests of the form: + + +http://couchdb:5984/PREFIX/path + + + To: + + +DESTINATION/path + + + + Everything after PREFIX including the + required forward slash will be appended to the + DESTINATION. + + + + + The response is then communicated back to the original client. + + + + For example, the following configuration: + + +_google = {couch_httpd_proxy, handle_proxy_req, <<"http://www.google.com">>} + + + Would forward all requests for + http://couchdb:5984/_google to the Google + website. + + + + The service can also be used to forward to related CouchDB + services, such as Lucene: + + +[httpd_global_handlers] +_fti = {couch_httpd_proxy, handle_proxy_req, <<"http://127.0.0.1:5985">>} + + + + The proxy service is basic. If the request is not identified by + the DESTINATION, or the remainder of the + PATH specification is incomplete, the + original request URL is interpreted as if the + PREFIX component of that URL does not exist. + + + + For example, requesting + http://couchdb:5984/_intranet/media when + /media on the proxy destination does not + exist, will cause the request URL to be interpreted as + http://couchdb:5984/media. Care should be + taken to ensure that both requested URLs and destination URLs + are able to cope + + + +

+ +

+ + CommonJS support for map functions + + + CommonJS support allows you to use CommonJS notation inside + map and reduce + functions, but only of libraries that are stored inside the views + part of the design doc. + + + + So you could continue to access CommonJS code in design_doc.foo, + from your list functions etc, but we'd add the ability to require + CommonJS modules within map and reduce, but only from + design_doc.views.lib. + + + + There's no worry here about namespace collisions, as Couch just + plucks views.*.map and + views.*.reduce out of the design doc. So you + could have a view called lib if you wanted, and + still have CommonJS stored in views.lib.sha1 + and views.lib.stemmer if you wanted. + + + + The implementation is simplified by enforcing that CommonJS + modules to be used in map functions be + stored in views.lib. + + + + A sample design doc (taken from the test suite in Futon) is below: + + +{ + "views" : { + "lib" : { + "baz" : "exports.baz = 'bam';", + "foo" : { + "zoom" : "exports.zoom = 'yeah';", + "boom" : "exports.boom = 'ok';", + "foo" : "exports.foo = 'bar';" + } + }, + "commonjs" : { + "map" : "function(doc) { emit(null, require('views/lib/foo/boom').boom)}" + } + }, + "_id" : "_design/test" +} + + + The require() statement is relative to the + design document, but anything loaded form outside of + views/lib will fail. + + +

+ +

+ + Granular ETag support + + + ETags have been assigned to a map/reduce group (the collection of + views in a single design document). Any change to any of the + indexes for those views would generate a new ETag for all view + URL's in a single design doc, even if that specific view's results + had not changed. + + + + In CouchDB 1.1 each _view URL has it's own ETag + which only gets updated when changes are made to the database that + effect that index. If the index for that specific view does not + change, that view keeps the original ETag head (therefore sending + back 304 Not Modified more often). + + +

+ + + + + + Replication + + + + + +

+ + Replicator Database + + + A database where you + PUT/POST documents to + trigger replications and you DELETE to cancel + ongoing replications. These documents have exactly the same + content as the JSON objects we used to POST to + _replicate (fields source, + target, create_target, + continuous, doc_ids, + filter, query_params. + + + + Replication documents can have a user defined + _id. Design documents (and + _local documents) added to the replicator + database are ignored. + + + + The default name of this database is + _replicator. The name can be changed in the + local.ini configuration, section + [replicator], parameter db. + + +

+ + Basics + + + Let's say you PUT the following document into _replicator: + + +{ + "_id": "my_rep", + "source": "http://myserver.com:5984/foo", + "target": "bar", + "create_target": true +} + + + In the couch log you'll see 2 entries like these: + + +[Thu, 17 Feb 2011 19:43:59 GMT] [info] [<0.291.0>] Document `my_rep` triggered replication `c0ebe9256695ff083347cbf95f93e280+create_target` +[Thu, 17 Feb 2011 19:44:37 GMT] [info] [<0.124.0>] Replication `c0ebe9256695ff083347cbf95f93e280+create_target` finished (triggered by document `my_rep`) + + + As soon as the replication is triggered, the document will be + updated by CouchDB with 3 new fields: + + +{ + "_id": "my_rep", + "source": "http://myserver.com:5984/foo", + "target": "bar", + "create_target": true, + "_replication_id": "c0ebe9256695ff083347cbf95f93e280", + "_replication_state": "triggered", + "_replication_state_time": 1297974122 +} + + + Special fields set by the replicator start with the prefix + _replication_. + + + + + + + _replication_id + + + + The ID internally assigned to the replication. This is also + the ID exposed by /_active_tasks. + + + + + + _replication_state + + + + The current state of the replication. + + + + + + _replication_state_time + + + + A Unix timestamp (number of seconds since 1 Jan 1970) that + tells us when the current replication state (marked in + _replication_state) was set. + + + + + + + When the replication finishes, it will update the + _replication_state field (and + _replication_state_time) with the value + completed, so the document will look like: + + +{ + "_id": "my_rep", + "source": "http://myserver.com:5984/foo", + "target": "bar", + "create_target": true, + "_replication_id": "c0ebe9256695ff083347cbf95f93e280", + "_replication_state": "completed", + "_replication_state_time": 1297974122 +} + + + When an error happens during replication, the + _replication_state field is set to + error (and + _replication_state gets updated of course). + + + + When you PUT/POST a document to the + _replicator database, CouchDB will attempt to + start the replication up to 10 times (configurable under + [replicator], parameter + max_replication_retry_count). If it fails on + the first attempt, it waits 5 seconds before doing a second + attempt. If the second attempt fails, it waits 10 seconds before + doing a third attempt. If the third attempt fails, it waits 20 + seconds before doing a fourth attempt (each attempt doubles the + previous wait period). When an attempt fails, the Couch log will + show you something like: + + +[error] [<0.149.0>] Error starting replication `67c1bb92010e7abe35d7d629635f18b6+create_target` (document `my_rep_2`): {db_not_found,<<"could not open http://myserver:5986/foo/">> + + + + The _replication_state field is only set to + error when all the attempts were + unsuccessful. + + + + + There are only 3 possible values for the + _replication_state field: + triggered, completed and + error. Continuous replications never get + their state set to completed. + + +

+ +

+ + Documents describing the same replication + + + Lets suppose 2 documents are added to the + _replicator database in the following order: + + +{ + "_id": "doc_A", + "source": "http://myserver.com:5984/foo", + "target": "bar" +} + + + and + + +{ + "_id": "doc_B", + "source": "http://myserver.com:5984/foo", + "target": "bar" +} + + + Both describe exactly the same replication (only their + _ids differ). In this case document + doc_A triggers the replication, getting + updated by CouchDB with the fields + _replication_state, + _replication_state_time and + _replication_id, just like it was described + before. Document doc_B however, is only + updated with one field, the _replication_id + so it will look like this: + + +{ + "_id": "doc_B", + "source": "http://myserver.com:5984/foo", + "target": "bar", + "_replication_id": "c0ebe9256695ff083347cbf95f93e280" +} + + + While document doc_A will look like this: + + +{ + "_id": "doc_A", + "source": "http://myserver.com:5984/foo", + "target": "bar", + "_replication_id": "c0ebe9256695ff083347cbf95f93e280", + "_replication_state": "triggered", + "_replication_state_time": 1297974122 +} + + + Note that both document get exactly the same value for the + _replication_id field. This way you can + identify which documents refer to the same replication - you can + for example define a view which maps replication IDs to document + IDs. + + +

+ +

+ + Canceling replications + + + To cancel a replication simply DELETE the + document which triggered the replication. The Couch log will + show you an entry like the following: + + +[Thu, 17 Feb 2011 20:16:29 GMT] [info] [<0.125.0>] Stopped replication `c0ebe9256695ff083347cbf95f93e280+continuous+create_target` because replication document `doc_A` was deleted + + + + You need to DELETE the document that + triggered the replication. DELETEing + another document that describes the same replication but did + not trigger it, will not cancel the replication. + + + +

+ +

+ + Server restart + + + When CouchDB is restarted, it checks its + _replicator database and restarts any + replication that is described by a document that either has its + _replication_state field set to + triggered or it doesn't have yet the + _replication_state field set. + + + + + Continuous replications always have a + _replication_state field with the value + triggered, therefore they're always + restarted when CouchDB is restarted. + + + +

+ +

+ + Changing the Replicator Database + + + Imagine your replicator database (default name is _replicator) + has the two following documents that represent pull replications + from servers A and B: + + +{ + "_id": "rep_from_A", + "source": "http://aserver.com:5984/foo", + "target": "foo_a", + "continuous": true, + "_replication_id": "c0ebe9256695ff083347cbf95f93e280", + "_replication_state": "triggered", + "_replication_state_time": 1297971311 +} +{ + "_id": "rep_from_B", + "source": "http://bserver.com:5984/foo", + "target": "foo_b", + "continuous": true, + "_replication_id": "231bb3cf9d48314eaa8d48a9170570d1", + "_replication_state": "triggered", + "_replication_state_time": 1297974122 +} + + + Now without stopping and restarting CouchDB, you change the name + of the replicator database to + another_replicator_db: + + +$ curl -X PUT http://localhost:5984/_config/replicator/db -d '"another_replicator_db"' +"_replicator" + + + As soon as this is done, both pull replications defined before, + are stopped. This is explicitly mentioned in CouchDB's log: + + +[Fri, 11 Mar 2011 07:44:20 GMT] [info] [<0.104.0>] Stopping all ongoing replications because the replicator database was deleted or changed +[Fri, 11 Mar 2011 07:44:20 GMT] [info] [<0.127.0>] 127.0.0.1 - - PUT /_config/replicator/db 200 + + + Imagine now you add a replication document to the new replicator + database named another_replicator_db: + + +{ + "_id": "rep_from_X", + "source": "http://xserver.com:5984/foo", + "target": "foo_x", + "continuous": true +} + + + From now own you have a single replication going on in your + system: a pull replication pulling from server X. Now you change + back the replicator database to the original one + _replicator: + + +$ curl -X PUT http://localhost:5984/_config/replicator/db -d '"_replicator"' +"another_replicator_db" + + + Immediately after this operation, the replication pulling from + server X will be stopped and the replications defined in the + _replicator database (pulling from servers A and B) will be + resumed. + + + + Changing again the replicator database to + another_replicator_db will stop the pull + replications pulling from servers A and B, and resume the pull + replication pulling from server X. + + +

+ +

+ + Replicating the replicator database + + + Imagine you have in server C a replicator database with the two + following pull replication documents in it: + + +{ + "_id": "rep_from_A", + "source": "http://aserver.com:5984/foo", + "target": "foo_a", + "continuous": true, + "_replication_id": "c0ebe9256695ff083347cbf95f93e280", + "_replication_state": "triggered", + "_replication_state_time": 1297971311 +} +{ + "_id": "rep_from_B", + "source": "http://bserver.com:5984/foo", + "target": "foo_b", + "continuous": true, + "_replication_id": "231bb3cf9d48314eaa8d48a9170570d1", + "_replication_state": "triggered", + "_replication_state_time": 1297974122 +} + + + Now you would like to have the same pull replications going on + in server D, that is, you would like to have server D pull + replicating from servers A and B. You have two options: + + + + + + + Explicitly add two documents to server's D replicator + database + + + + + + Replicate server's C replicator database into server's D + replicator database + + + + + + + Both alternatives accomplish exactly the same goal. + + +

+ +

+ + Delegations + + + Replication documents can have a custom + user_ctx property. This property defines the + user context under which a replication runs. For the old way of + triggering replications (POSTing to + /_replicate/), this property was not needed + (it didn't exist in fact) - this is because at the moment of + triggering the replication it has information about the + authenticated user. With the replicator database, since it's a + regular database, the information about the authenticated user + is only present at the moment the replication document is + written to the database - the replicator database implementation + is like a _changes feed consumer (with + ?include_docs=true) that reacts to what was + written to the replicator database - in fact this feature could + be implemented with an external script/program. This + implementation detail implies that for non admin users, a + user_ctx property, containing the user's name + and a subset of his/her roles, must be defined in the + replication document. This is ensured by the document update + validation function present in the default design document of + the replicator database. This validation function also ensure + that a non admin user can set a user name property in the + user_ctx property that doesn't match his/her + own name (same principle applies for the roles). + + + + For admins, the user_ctx property is + optional, and if it's missing it defaults to a user context with + name null and an empty list of roles - this mean design + documents will not be written to local targets. If writing + design documents to local targets is desired, the a user context + with the roles _admin must be set explicitly. + + + + Also, for admins the user_ctx property can be + used to trigger a replication on behalf of another user. This is + the user context that will be passed to local target database + document validation functions. + + + + + The user_ctx property only has effect for + local endpoints. + + + + + Example delegated replication document: + + +{ + "_id": "my_rep", + "source": "http://bserver.com:5984/foo", + "target": "bar", + "continuous": true, + "user_ctx": { + "name": "joe", + "roles": ["erlanger", "researcher"] + } +} + + + As stated before, for admins the user_ctx property is optional, + while for regular (non admin) users it's mandatory. When the + roles property of user_ctx is missing, it + defaults to the empty list [ ]. + + +

+ +

+ + + + + + + + CouchDB API + + + The CouchDB API is the primary method of interfacing to a CouchDB + instance. Requests are made using HTTP and requests are used to + request information from the database, store new data, and perform + views and formatting of the information stored within the documents. + + + + Requests to the API can be categorised by the different areas of the + CouchDB system that you are accessing, and the HTTP method used to + send the request. Different methods imply different operations, for + example retrieval of information from the database is typically + handled by the GET operation, while updates are + handled by either a POST or + PUT request. There are some differences between + the information that must be supplied for the different methods. For + a guide to the basic HTTP methods and request structure, see + . + + + + For nearly all operations, the submitted data, and the returned data + structure, is defined within a JavaScript Object Notation (JSON) + object. Basic information on the content and data types for JSON are + provided in . + + + + Errors when accessing the CouchDB API are reported using standard + HTTP Status Codes. A guide to the generic codes returned by CouchDB + are provided in + . + + + + When accessing specific areas of the CouchDB API, specific + information and examples on the HTTP methods and request, JSON + structures, and error codes are provided. For a guide to the + different areas of the API, see + . + + +

+ + Request Format and Responses + + + CouchDB supports the following HTTP request methods: + + + + + + + GET + + + + Request the specified item. As with normal HTTP requests, the + format of the URL defines what is returned. With CouchDB this + can include static items, database documents, and + configuration and statistical information. In most cases the + information is returned in the form of a JSON document. + + + + + + HEAD + + + + The HEAD method is used to get the HTTP + header of a GET request without the body of + the response. + + + + + + POST + + + + Upload data. Within CouchDB POST is used to + set values, including uploading documents, setting document + values, and starting certain administration commands. + + + + + + PUT + + + + Used to put a specified resource. In CouchDB + PUT is used to create new objects, + including databases, documents, views and design documents. + + + + + + DELETE + + + + Deletes the specified resource, including documents, views, + and design documents. + + + + + + COPY + + + + A special method that can be used to copy documents and + objects. + + + + + + + If you use the an unsupported HTTP request type with a URL that + does not support the specified type, a 405 error will be returned, + listing the supported HTTP methods. For example: + + +{ + "error":"method_not_allowed", + "reason":"Only GET,HEAD allowed" +} + + + + + The CouchDB design document API and the functions when returning + HTML (for example as part of a show or list) enables you to + include custom HTTP headers through the headers + block of the return object. For more information, see + . + + +

+ +

+ + HTTP Headers + + + Because CouchDB uses HTTP for all communication, you need to + ensure that the correct HTTP headers are supplied (and processed + on retrieval) so that you get the right format and encoding. + Different environments and clients will be more or less strict on + the effect of these HTTP headers (especially when not present). + Where possible you should be as specific as possible. + + +

+ + Request Headers + + + + + + Content-type + + + + Specifies the content type of the information being supplied + within the request. The specification uses MIME type + specifications. For the majority of requests this will be + JSON (application/json). For some + settings the MIME type will be plain text. When uploading + attachments it should be the corresponding MIME type for the + attachment or binary + (application/octet-stream). + + + + The use of the Content-type on a request + is highly recommended. + + + + + + Accept + + + + Specifies the list of accepted data types to be returned by + the server (i.e. that are accepted/understandable by the + client). The format should be a list of one or more MIME + types, separated by colons. + + + + For the majority of requests the definition should be for + JSON data (application/json). For + attachments you can either specify the MIME type explicitly, + or use */* to specify that all file types + are supported. If the Accept header is + not supplied, then the */* MIME type is + assumed (i.e. client accepts all formats). + + + + The use of Accept in queries for CouchDB + is not required, but is highly recommended as it helps to + ensure that the data returned can be processed by the + client. + + + + If you specify a data type using the + Accept header, CouchDB will honor the + specified type in the Content-type header + field returned. For example, if you explicitly request + application/json in the + Accept of a request, the returned HTTP + headers will use the value in the returned + Content-type field. + + + + For example, when sending a request without an explicit + Accept header, or when specifying + */*: + + +GET /recipes HTTP/1.1 +Host: couchdb:5984 +Accept: */* + + + The returned headers are: + + +Server: CouchDB/1.0.1 (Erlang OTP/R13B) +Date: Thu, 13 Jan 2011 13:39:34 GMT +Content-Type: text/plain;charset=utf-8 +Content-Length: 227 +Cache-Control: must-revalidate + + + Note that the returned content type is + text/plain even though the information + returned by the request is in JSON format. + + + + Explicitly specifying the Accept header: + + +GET /recipes HTTP/1.1 +Host: couchdb:5984 +Accept: application/json + + + The headers returned include the + application/json content type: + + +Server: CouchDB/1.0.1 (Erlang OTP/R13B) +Date: Thu, 13 Jan 2011 13:40:11 GMT +Content-Type: application/json +Content-Length: 227 +Cache-Control: must-revalidate + + + + +

+ +

+ + Response Headers + + + Response headers are returned by the server when sending back + content and include a number of different header fields, many of + which are standard HTTP response header and have no significance + to CouchDB operation. The list of response headers important to + CouchDB are listed below. + + + + + + + Content-type + + + + Specifies the MIME type of the returned data. For most + request, the returned MIME type is + text/plain. All text is encoded in + Unicode (UTF-8), and this is explicitly stated in the + returned Content-type, as + text/plain;charset=utf-8. + + + + + + Cache-control + + + + The cache control HTTP response header provides a suggestion + for client caching mechanisms on how to treat the returned + information. CouchDB typically returns the + must-revalidate, which indicates that the + information should be revalidated if possible. This is used + to ensure that the dynamic nature of the content is + correctly updated. + + + + + + Content-length + + + + The length (in bytes) of the returned content. + + + + + + Etag + + + + The Etag HTTP header field is used to + show the revision for a document. + + + + + +

+ +

+ + JSON Basics + + + The majority of requests and responses to CouchDB use the + JavaScript Object Notation (JSON) for formatting the content and + structure of the data and responses. + + + + JSON is used because it is the simplest and easiest to use + solution for working with data within a web browser, as JSON + structures can be evaluated and used as JavaScript objects within + the web browser environment. JSON also integrates with the + server-side JavaScript used within CouchDB. + + + + JSON supports the same basic types as supported by JavaScript, + these are: + + + + + + + Number (either integer or floating-point). + + + + + + String; this should be enclosed by double-quotes and supports + Unicode characters and backslash escaping. For example: + + +"A String" + + + + + Boolean - a true or + false value. You can use these strings + directly. For example: + + +{ "value": true} + + + + + Array - a list of values enclosed in square brackets. For + example: + + +["one", "two", "three"] + + + + + Object - a set of key/value pairs (i.e. an associative array, + or hash). The key must be a string, but the value can be any + of the supported JSON values. For example: + + +{ + "servings" : 4, + "subtitle" : "Easy to make in advance, and then cook when ready", + "cooktime" : 60, + "title" : "Chicken Coriander" +} + + + In CouchDB, the JSON object is used to represent a variety of + structures, including the main CouchDB document. + + + + + + + Parsing JSON into a JavaScript object is supported through the + eval() function in JavaScript, or through + various libraries that will perform the parsing of the content + into a JavaScript object for you. Libraries for parsing and + generating JSON are available in many languages, including Perl, + Python, Ruby, Erlang and others. + + + + + Care should be taken to ensure that your JSON structures are + valid, invalid structures will cause CouchDB to return an HTTP + status code of 500 (server error). See + + . + + + +

+ +

+ + HTTP Status Codes + + + With the interface to CouchDB working through HTTP, error codes + and statuses are reported using a combination of the HTTP status + code number, and corresponding data in the body of the response + data. + + + + A list of the error codes returned by CouchDB, and generic + descriptions of the related errors are provided below. The meaning + of different status codes for specific request types are provided + in the corresponding API call reference. + + + + + + + 200 - OK + + + + Request completed successfully. + + + + + + 201 - Created + + + + Document created successfully. + + + + + + 202 - Accepted + + + + Request has been accepted, but the corresponding operation may + not have completed. This is used for background operations, + such as database compaction. + + + + + + 304 - Not Modified + + + + The additional content requested has not been modified. This + is used with the ETag system to identify the version of + information returned. + + + + + + 400 - Bad Request + + + + Bad request structure. The error can indicate an error with + the request URL, path or headers. Differences in the supplied + MD5 hash and content also trigger this error, as this may + indicate message corruption. + + + + + + 401 - Unauthorized + + + + The item requested was not available using the supplied + authorization, or authorization was not supplied. + + + + + + 403 - Forbidden + + + + The requested item or operation is forbidden. + + + + + + 404 - Not Found + + + + The requested content could not be found. The content will + include further information, as a JSON object, if available. + The structure will contain two keys, error + and reason. For example: + + +{"error":"not_found","reason":"no_db_file"} + + + + + 405 - Resource Not Allowed + + + + A request was made using an invalid HTTP request type for the + URL requested. For example, you have requested a + PUT when a POST is + required. Errors of this type can also triggered by invalid + URL strings. + + + + + + 406 - Not Acceptable + + + + The requested content type is not supported by the server. + + + + + + 409 - Conflict + + + + Request resulted in an update conflict. + + + + + + 412 - Precondition Failed + + + + The request headers from the client and the capabilities of + the server do not match. + + + + + + 415 - Bad Content Type + + + + The content types supported, and the content type of the + information being requested or submitted indicate that the + content type is not supported. + + + + + + 416 - Requested Range Not Satisfiable + + + + The range specified in the request header cannot be satisfied + by the server. + + + + + + 417 - Expectation Failed + + + + When sending documents in bulk, the bulk load operation + failed. + + + + + + 500 - Internal Server Error + + + + The request was invalid, either because the supplied JSON was + invalid, or invalid information was supplied as part of the + request. + + + + + +

+ +

+ + CouchDB API Overview + + + The components of the API URL path help determine the part of the + CouchDB server that is being accessed. The result is the structure + of the URL request both identifies and effectively describes the + area of the database you are accessing. + + + + As with all URLs, the individual components are separated by a + forward slash. + + + + As a general rule, URL components and JSON fields starting with + the _ (underscore) character represent a + special component or entity within the server or returned object. + For example, the URL fragment /_all_dbs gets a + list of all of the databases in a CouchDB instance. + + + + The remainder of the URL API structure can be divided up according + to the URL structure. The different sections are divided as + follows: + + + + + + + /db + + + + Database methods, related to adding, updating or deleting + databases, and setting database parameters and operations. For + more detailed information, see + . + + + + + + /db/doc + + + + Document methods, those that create, store, update or delete + CouchDB documents and their attachments. For more information, + see . + + + + + + /db/_local/local-doc + + + + Document methods, those that create, store, update or delete + CouchDB documents only within the local database. Local + documents are not synchronized with other databases. For more + information, see + . + + + + + + /db/_design/design-doc + + + + Design documents provide the methods and structure for + recovering information from a CouchDB database in the form of + views, shows and lists. For more information, see + . + + + + + + /_special + + + + Special methods that obtain or set information about the + CouchDB instance, including methods for configuring + replication, accessing the logs, and generate Universally + Unique IDs (UUIDs). For more information, see + . + + + + + + /_config + + + + Methods for getting, and settings, CouchDB configuration + parameters. For more information, see + . + + + + + + + +

+ + + + + + CouchDB API Server Database Methods + + + The Database methods provide an interface to an entire database + withing CouchDB. These are database, rather than document, level + requests. + + + + A list of the available methods and URL paths are provided below: + + + + + + + +Database API CallsMethodPathDescriptionGET/db + Returns database information + PUT/db + Create a new database + DELETE/db + Delete an existing database + GET/db/_all_docs + Returns a built-in view of all documents in this database + POST/db/_all_docs + Returns certain rows from the built-in view of all documents + POST/db/_bulk_docs + Insert multiple documents in to the database in a single request + GET/db/_changes + Returns changes for the given database + POST/db/_compact + Starts a compaction for the database + POST/db/_compact/design-doc + Starts a compaction for all the views in the selected design + document + POST/db/_ensure_full_commit + Makes sure all uncommitted changes are written and synchronized + to the disk + POST/db/_missing_revs + Given a list of document revisions, returns the document + revisions that do not exist in the database + POST/db/_purge + Purge some historical documents entirely from database history + POST/db/_revs_diff + Given a list of document revisions, returns differences between + the given revisions and ones that are in the database + GET/db/_revs_limit + Gets the limit of historical revisions to store for a single + document in the database + PUT/db/_revs_limit + Sets the limit of historical revisions to store for a single + document in the database + GET/db/_security + Returns the special security object for the database + PUT/db/_security + Sets the special security object for the database + POST/db/_temp_view + Execute a given view function for all documents and return the + result + POST/db/_view_cleanup + Removes view files that are not used by any design document +

+ + + For all the database methods, the database name within the URL path + should be the database name that you wish to perform the operation + on. For example, to obtain the meta information for the database + recipes, you would use the HTTP request: + + +GET /recipes + + + For clarity, the form below is used in the URL paths: + + +GET /db + + + Where db is the name of any database. + + +

+ + <literal moreinfo="none">GET /db</literal> + + + + + + +URL API GET /dbMethodGET /dbRequest + None + Response + Information about the database in JSON format + Admin Privileges RequirednoReturn Codes404 + The requested content could not be found. The returned content + will include further information, as a JSON object, if available. + + + + Gets information about the specified database. For example, to + retrieve the information for the database + recipe: + + +GET http://couchdb:5984/recipes +Accept: application/json + + + The JSON response contains meta information about the database. A + sample of the JSON returned for an empty database is provided + below: + + +{ + "compact_running" : false, + "committed_update_seq" : 375048, + "disk_format_version" : 5, + "disk_size" : 33153123, + "doc_count" : 18386, + "doc_del_count" : 0, + "db_name" : "recipes", + "instance_start_time" : "1290700340925570", + "purge_seq" : 10, + "update_seq" : 375048 +} + + + The elements of the returned structure are shown in the table + below: + + + + + + + + + CouchDB database information object + FieldDescriptioncommitted_update_seq + The number of committed update. + compact_running + Set to true if the database compaction routine is operating on + this database. + db_name + The name of the database. + disk_format_version + The version of the physical format used for the data when it is + stored on disk. + disk_size + Size in bytes of the data as stored on the disk. Views indexes + are not included in the calculation. + doc_count + A count of the documents in the specified database. + doc_del_count + Number of deleted documents + instance_start_time + Timestamp of when the database was created, expressed in + milliseconds since the epoch. + purge_seq + The number of purge operations on the database. + update_seq + The current number of updates to the database. +

+ +

+ + <literal moreinfo="none">PUT /db</literal> + + + + + + +URL API PUT /dbMethodPUT /dbRequest + None + Response + JSON success statement + Admin Privileges RequirednoReturn Codes400 + Invalid database name + 412 + Database already exists + + + + Creates a new database. The database name must be composed of one + or more of the following characters: + + + + + + + Lowercase characters (a-z) + + + + + + Name must begin with a lowercase letter + + + + + + Digits (0-9) + + + + + + Any of the characters _, + $, (, + ), +, + -, and /. + + + + + + + Trying to create a database that does not meet these requirements + will return an error quoting these restrictions. + + + + To create the database recipes: + + +PUT http://couchdb:5984/recipes +Content-Type: application/json + + + The returned content contains the JSON status: + + +{ + "ok" : true +} + + + Anything should be treated as an error, and the problem should be + taken form the HTTP response code. + + +

+ +

+ + <literal moreinfo="none">DELETE /db</literal> + + + + +