# 1.5.1. `/{db}/_design/{ddoc}`

HEAD /{db}/_design/{ddoc}

  Returns the HTTP Headers containing a minimal amount of information about the specified design document.

  See also

  `HEAD /{db}/{docid}`

GET /{db}/_design/{ddoc}

  Returns the contents of the design document specified with the name of the design document and from the specified database from the URL. Unless you request a specific revision, the latest revision of the document will always be returned.

  See also

  `GET /{db}/{docid}`

PUT /{db}/_design/{ddoc}

  The PUT method creates a new named design document, or creates a new revision of the existing design document.

  The design documents have some agreement upon their fields and structure. Currently it is the following:

  - language (string): Defines Query Server to process design document functions

  - options (object): View’s default options

  - filters (object): Filter functions definition

  - lists (object): List functions definition. Deprecated.

  - rewrites (array or string): Rewrite rules definition. Deprecated.

  - shows (object): Show functions definition. Deprecated.

  - updates (object): Update functions definition

  - validate_doc_update (string): Validate document update function source

  - views (object): View functions definition.

  - autoupdate (boolean): Indicates whether to automatically build indexes defined in this design document. Default is `true`.

  Note, that for `filters`, `lists`, `shows` and `updates` fields objects are mapping of function name to string function source code. For `views` mapping is the same except that values are objects with `map` and `reduce` (optional) keys which also contains functions source code.

  See also

  `PUT /{db}/{docid}`

DELETE /{db}/_design/{ddoc}

  Deletes the specified document from the database. You must supply the current (latest) revision, either by using the `rev` parameter to specify the revision.

  See also

  `DELETE /{db}/{docid}`

COPY /{db}/_design/{ddoc}

  The COPY (which is non-standard HTTP) copies an existing design document to a new or existing one.

  Given that view indexes on disk are named after their MD5 hash of the view definition, and that a COPY operation won’t actually change that definition, the copied views won’t have to be reconstructed. Both views will be served from the same index on disk.

  See also

  `COPY /{db}/{docid}`

# 1.5.2. `/{db}/_design/{ddoc}/{attname}`

HEAD /{db}/_design/{ddoc}/{attname}

  Returns the HTTP headers containing a minimal amount of information about the specified attachment.

  See also

  `HEAD /{db}/{docid}/{attname}`

GET /{db}/_design/{ddoc}/{attname}

  Returns the file attachment associated with the design document. The raw data of the associated attachment is returned (just as if you were accessing a static file.

  See also

  `GET /{db}/{docid}/{attname}`

PUT /{db}/_design/{ddoc}/{attname}

  Uploads the supplied content as an attachment to the specified design document. The attachment name provided must be a URL encoded string.

  See also

  `PUT /{db}/{docid}/{attname}`

DELETE /{db}/_design/{ddoc}/{attname}

  Deletes the attachment of the specified design document.

  See also

  `DELETE /{db}/{docid}/{attname}`

# 1.5.3. `/{db}/_design/{ddoc}/_info`

GET /{db}/_design/{ddoc}/_info

  Obtains information about the specified design document, including the index, index size and current status of the design document and associated index information.

  Parameters:

    - db – Database name

    - ddoc – Design document name

  Request Headers:

    - Accept –

      - application/json

      - text/plain

  Response Headers:

    - Content-Type –

      - application/json

      - text/plain; charset=utf-8

  Response JSON Object:

    - name (string) – Design document name

    - view_index (object) – View Index Information

  Status Codes:

    - 200 OK – Request completed successfully

    - 401 Unauthorized – Unauthorized request to a protected API

    - 403 Forbidden – Insufficient permissions / Too many requests with invalid credentials

  Request:

      GET /recipes/_design/recipe/_info HTTP/1.1
      Accept: application/json
      Host: localhost:5984

  Response:

      HTTP/1.1 200 OK
      Cache-Control: must-revalidate
      Content-Length: 263
      Content-Type: application/json
      Date: Sat, 17 Aug 2013 12:54:17 GMT
      Server: CouchDB (Erlang/OTP)

      {
          "name": "recipe",
          "view_index": {
              "compact_running": false,
              "language": "python",
              "purge_seq": 0,
              "signature": "a59a1bb13fdf8a8a584bc477919c97ac",
              "sizes": {
                "active": 926691,
                "disk": 1982704,
                "external": 1535701
              },
              "update_seq": 12397,
              "updater_running": false,
              "waiting_clients": 0,
              "waiting_commit": false
          }
      }

## 1.5.3.1. View Index Information

The response from `GET /{db}/_design/{ddoc}/_info` contains `view_index` (object) field with the next structure:

- compact_running (boolean): Indicates whether a compaction routine is currently running on the view

- sizes.active (number): The size of live data inside the view, in bytes

- sizes.external (number): The uncompressed size of view contents in bytes

- sizes.file (number): Size in bytes of the view as stored on disk

- language (string): Language for the defined views

- purge_seq (number): The purge sequence that has been processed

- signature (string): MD5 signature of the views for the design document

- update_seq (number / string): The update sequence of the corresponding database that has been indexed

- updater_running (boolean): Indicates if the view is currently being updated

- waiting_clients (number): Number of clients waiting on views from this design document

- waiting_commit (boolean): Indicates if there are outstanding commits to the underlying database that need to processed