Crear datos adjuntos
La Create Attachment operación crea datos adjuntos para un documento.
Solicitud
| Método | URI de solicitud | Descripción |
|---|---|---|
| POST | https://{databaseaccount}.documents.azure.com/dbs/{db-id}/colls/{coll-id}/docs/{doc-name}/attachments. | {databaseaccount} es el nombre de la cuenta de Azure Cosmos DB creada en la suscripción. El valor {db-id} es el nombre o identificador generado por el usuario de la base de datos, no el identificador generado por el sistema (rid). El valor {coll-id} es el nombre de la colección en la que se encuentra el documento. El valor {doc-name} es el nombre del documento asociado a los datos adjuntos. |
encabezados
Consulte Encabezados de solicitud REST comunes de Azure Cosmos DB para ver los encabezados que usan todas las solicitudes de Azure Cosmos DB.
| Encabezado | Obligatorio | Tipo | Descripción |
|---|---|---|---|
| Slug | Opcionales | String | El nombre de los datos adjuntos. Solo es necesario cuando los medios sin procesar se envían al almacenamiento de datos adjuntos de Azure Cosmos DB. Para obtener más información, consulte Protocolo AtomPub. |
Body
| Propiedad | Obligatorio | Tipo | Descripción |
|---|---|---|---|
| id | Opcionales | String | No se requiere definir cuando se adjunta multimedia sin procesar. Es una propiedad que se puede establecer por el usuario. Es el nombre único que identifica los datos adjuntos, es decir, ningún dato adjunto comparte el mismo identificador. El identificador no debe superar los 255 caracteres. |
| contentType | Opcionales | String | No se requiere definir cuando se adjunta multimedia sin procesar. Es una propiedad que se puede establecer por el usuario. Indica el tipo de contenido de los datos adjuntos. Al enviar los bits de datos adjuntos como cuerpo, Cosmos DB establece contentType en el tipo establecido en el encabezado Content-Type . |
| Elementos multimedia | Opcionales | String | No se requiere definir cuando se adjunta multimedia sin procesar. Es el vínculo de dirección URL o la ruta de acceso del archivo donde residen los datos adjuntos. |
{
"id": "image_id",
"contentType": "image/jpg",
"media": "www.bing.com"
}
Response
encabezados
Consulte Encabezados de respuesta REST comunes de Azure Cosmos DB para ver los encabezados devueltos por todas las respuestas de Azure Cosmos DB.
Códigos de estado
La tabla siguiente muestra los códigos de estado comunes que devuelve esta operación. Para obtener una lista completa de los códigos de estado, consulte Códigos de estado HTTP.
| Código de estado HTTP | Descripción |
|---|---|
| 201 Creado | La operación se realizó correctamente. |
| 400 - Solicitud incorrecta | El cuerpo JSON no es válido. Compruebe si faltan llaves o comillas. |
| 409 Conflicto | Un archivo adjunto existente ha tomado el identificador o slug proporcionado para los nuevos datos adjuntos. |
| 413 Entidad demasiado grande | El tamaño del documento en la solicitud supera el tamaño de documento permitido en una solicitud. |
Cuerpo
La creación de datos adjuntos da como resultado la creación de un recurso de datos adjuntos con el siguiente cuerpo de respuesta:
| Propiedad | Descripción |
|---|---|
| _Librar | Es una propiedad generada por el sistema. El identificador de recurso (_rid) es un identificador único que también es jerárquico por la pila de recursos en el modelo de recursos. Se usa internamente para la colocación y el desplazamiento del recurso de datos adjuntos. |
| _Ts | Es una propiedad generada por el sistema. Especifica la última marca de tiempo actualizada del recurso. El valor es una marca de tiempo. |
| _propio | Es una propiedad generada por el sistema. Es el URI direccionable único para el recurso. |
| _Etag | Es una propiedad generada por el sistema que especifica la etag de recursos necesaria para el control de simultaneidad optimista. |
{
"id": "image_id",
"contentType": "image/jpg",
"media": "www.bing.com",
"_rid": "Sl8fALN4sw4CAAAAAAAAAOnTcEc=",
"_ts": 1449606296,
"_self": "dbs\/Sl8fAA==\/colls\/Sl8fALN4sw4=\/docs\/Sl8fALN4sw4CAAAAAAAAAA==\/attachments\/Sl8fALN4sw4CAAAAAAAAAOnTcEc=",
"_etag": "\"060091c2-0000-0000-0000-56673c980000\""
}
Ejemplo
POST https://contosomarketing.documents.azure.com/dbs/volcanodb/colls/volcano1/docs/c3bb1fef-fcb1-56e3-0389-f88583c3ce0d/attachments HTTP/1.1
x-ms-session-token: 16
x-ms-date: Tue, 08 Dec 2015 20:24:56 GMT
authorization: type%3dmaster%26ver%3d1.0%26sig%3dQ8MDtRExrtOeDL5TSaHvXhPTNyKiRrrIC3IjTSpf958%3d
Cache-Control: no-cache
User-Agent: contoso/1.0
x-ms-version: 2015-08-06
Accept: application/json
Host: contosomarketing.documents.azure.com
Cookie: x-ms-session-token=16
Content-Length: 66
Expect: 100-continue
Connection: Keep-Alive
{
"id": "image_id",
"contentType": "image/jpg",
"media": "www.bing.com"
}
HTTP/1.1 201 Created
Cache-Control: no-store, no-cache
Pragma: no-cache
Content-Type: application/json
Server: Microsoft-HTTPAPI/2.0
x-ms-max-media-storage-usage-mb: 2048
x-ms-media-storage-usage-mb: 0
Strict-Transport-Security: max-age=31536000
x-ms-last-state-change-utc: Sun, 29 Nov 2015 19:20:18.154 GMT
etag: "060091c2-0000-0000-0000-56673c980000"
x-ms-resource-quota: documentSize=10240;documentsSize=10485760;collectionSize=10485760;
x-ms-resource-usage: documentSize=0;documentsSize=291;collectionSize=369;
x-ms-schemaversion: 1.1
x-ms-alt-content-path: dbs/volcanodb/colls/volcano1/docs/c3bb1fef-fcb1-56e3-0389-f88583c3ce0d
x-ms-content-path: Sl8fALN4sw4CAAAAAAAAAA==
x-ms-quorum-acked-lsn: 18
x-ms-session-token: 19
x-ms-current-write-quorum: 3
x-ms-current-replica-set-size: 4
x-ms-request-charge: 4.95
x-ms-serviceversion: version=1.5.57.3
x-ms-activity-id: c03c09bf-a791-4dad-b2f8-fa88fa1bce04
Set-Cookie: x-ms-session-token=19; Domain=contosomarketing.documents.azure.com; Path=/dbs/volcanodb/colls/volcano1
x-ms-gatewayversion: version=1.5.57.3
Date: Tue, 08 Dec 2015 20:24:57 GMT
Content-Length: 292
{
"id": "image_id",
"contentType": "image/jpg",
"media": "www.bing.com",
"_rid": "Sl8fALN4sw4CAAAAAAAAAOnTcEc=",
"_ts": 1449606296,
"_self": "dbs\/Sl8fAA==\/colls\/Sl8fALN4sw4=\/docs\/Sl8fALN4sw4CAAAAAAAAAA==\/attachments\/Sl8fALN4sw4CAAAAAAAAAOnTcEc=",
"_etag": "\"060091c2-0000-0000-0000-56673c980000\""
}
Comentarios
Hay dos maneras de crear un recurso de datos adjuntos: publicar el contenido multimedia en Cosmos DB, como en el protocolo AtomPub, o publicar solo los metadatos adjuntos en los medios almacenados externamente.
La primera es publicar los medios sin procesar en la carga del cuerpo para almacenarlo en el almacenamiento de datos adjuntos proporcionado en la cuenta de Cosmos DB. Para crear este tipo de datos adjuntos, debe incluir los datos adjuntos sin procesar (vídeo, audio, archivo, blob, etc.) como el cuerpo de post. Se deben establecer dos encabezados: Content-Type y Slug. El encabezado Content-Type se define en el tipo MIME de los datos adjuntos, mientras que el encabezado Slug se define en el nombre de los datos adjuntos.
La segunda forma de crear un recurso de datos adjuntos es realizar una operación POST de las propiedades del recurso de datos adjuntos que indica el tipo y el vínculo multimedia de los datos adjuntos. A diferencia del primer tipo de recurso de datos adjuntos, no debe establecer los encabezados Content-Type y Slug.