couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Couchdb Wiki] Update of "HTTP_Document_API" by BenjaminYoung
Date Mon, 15 Nov 2010 15:17:02 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The "HTTP_Document_API" page has been changed by BenjaminYoung.
http://wiki.apache.org/couchdb/HTTP_Document_API?action=diff&rev1=69&rev2=70

--------------------------------------------------

   "Body":"I decided today that I don't like baseball. I like plankton."
  }
  }}}
- 
  === Special Fields ===
  Note that any top-level fields within a JSON document containing a name that starts with
a ''_'' prefix are reserved for use by CouchDB itself. Also see [[Reserved_words]]. Currently
(0.10+) reserved fields are:
- 
  ||'''Field Name''' ||'''Description''' ||
  ||''_id'' ||The unique identifier of the document ('''mandatory''' and '''immutable''')
||
  ||''_rev'' ||The current MVCC-token/revision of this document ('''mandatory''' and '''immutable''')
||
@@ -59, +57 @@

  ||''_deleted_conflicts'' ||Information about conflicts ||
  
  
+ 
+ 
  To request a special field be returned along with the normal fields you get when you request
a document, add the desired field as a query parameter without the leading underscore in a
GET request:
+ 
  {{{
  curl -X GET 'http://localhost:5984/my_database/my_document?conflicts=true'
  }}}
- 
  This request will return a document that includes the special field '_conflicts' which contains
all the conflicting revisions of "my_document".
- 
  
  ==== Document IDs ====
  Document IDs don't have restrictions on what characters can be used. Although it should
work, it is recommended to use non-special characters for document IDs. Using special characters
you have to be aware of proper URL en-/decoding. Documents prefixed with ''_'' are special
documents:
@@ -141, +140 @@

  {"ok":{"_id":"test","_rev":"2-5bc3c6319edf62d4c624277fdd0ae191","hello":"foo"}}
  ]
  }}}
- 
- 
  === HEAD ===
- 
  A HEAD request returns basic information about the document, including its current revision.
  
  {{{
  HEAD /somedatabase/some_doc_id HTTP/1.0
  }}}
- 
  {{{
  HTTP/1.1 200 OK
  Etag: "946B7D1C"
  Date: Thu, 17 Aug 2006 05:39:28 +0000GMT
  Content-Type: application/json
  Content-Length: 256
- 
  }}}
- 
- 
  <<Anchor(create_or_update_document)>>
  
  === PUT ===
@@ -289, +281 @@

  
  {"ok":true,"rev":"2839830636"}
  }}}
- 
  === COPY ===
  Note that this is a non-standard extension to HTTP.
  
@@ -530, +521 @@

  }
  }}}
  === Standalone Attachments ===
- Note: This was added in version 0.9 of CouchDB. It is not available in earlier version.
+ Note: This was added in version 0.9 of CouchDB. It is not available in earlier versions.
  
  CouchDB allows to create, change and delete attachments without touching the actual document.
As a bonus feature, you do not have to base64 encode your data. This can significantly speed
up requests since CouchDB and your client do not have to do the base64 conversion.
  
  You need to specify a MIME type using the Content-Type header. CouchDB will serve the attachment
with the specified Content-Type when asked.
  
- To create an attachment:
+ To create an attachment on an existing document:
  
  {{{
  PUT somedatabase/document/attachment?rev=123 HTTP/1.0
@@ -545, +536 @@

  
  <JPEG data>
  }}}
+ Note: You'll need to include the "rev" query parameter if you're adding (or updating) an
attachment on an existing document. This is true anytime you update a document. If you don't
know the value of _rev on the document, you can retreive it with a lightweight [[#HEAD|HEAD
request]] or by GETing the whole document.
+ 
  CouchDB replies:
  
  {{{
@@ -588, +581 @@

  
  <JPEG data>
  }}}
- 
  === Compression of Attachments ===
  As of version 0.11, CouchDB, by default, will automatically compress certain attachment
types.  That is, based on the Content-Type header of the request CouchDB may perform compression
of the data.  This is done to reduce the amount of data being shuffled around during replication,
and in most cases it's probably what you want.  However, if uploading large files (e.g. a
200M CSV) you may want to tweak this configuration in order to avoid compression and therefore
reduce the network latency of the request.
  

Mime
View raw message