Attachments
The attachments resource, unlike others, represents both entity data and binary content.
Overview
Note the following:
-
Attachments currently are supported only in the workspace context (as the entity metadata reflects).
-
The attachments API provides generic access for all attachments in the workspace. As a result, for each entity that has the attachments feature, the attachment entity has a reference field to the entity.
-
The reference field names adhere to the following convention:
owner_<entity name>
Example: owner_test
The attachment entity must have a reference to only one owner entity.
-
Supported file types
The following file types are supported by default:
jpg bmp png word doc docx msg pdf xml xls xlsx ppt pptx zip txt wmv mp4 m4p mkv vob log wrf fbr jpeg Customize the supported file types by modifying the ATTACHMENTS_FILE_EXTENSION_WHITE_LIST configuration parameter. For details, see Configuration parameters.
The REST API checks that the file extension matches the binary content format. If the extension and the content format do not match, the attachment is not uploaded.
-
When supplying the attachment name in the request, extra spaces at the beginning or at the end of the file name are trimmed, and do not cause any errors.
-
Make sure the name does not start with a period ( . ) and does not contain any of the following characters:
/ \ : * ? " < > |
Attachment collection
In some of the HTTP methods, resource collection behaves as any other collection entity, representing only the attachment entity data without the binary content. In other HTTP methods, there is reference to binary content.
URI
Attachments are relevant only in the workspace context:
.../api/shared_spaces/<space_id>/workspaces/<workspace_id>/attachments
Note: For the syntax for specifying parameters in URIs, see Variables and values.
Supported HTTP request methods
The attachment collection supports the following HTTP methods:
Method |
Description |
---|---|
GET |
Retrieve data about the attachment, or the actual attachment. |
POST |
Create new attachments in a collection. |
PUT |
Update information about the attachment (not the binary data). |
DELETE |
Delete existing attachments. |
Note: To update an actual attachment (the binary data), DELETE the original attachment and POST a new one.
Actions on attachment collections
Attachment instance
The attachment instance contains both the attachment’s entity data and the binary content.
Supported HTTP request methods
The attachment instance supports the following HTTP methods:
Method |
Description |
---|---|
GET |
Retrieve data about the attachment, or the actual attachment. |
POST |
Create new attachments in a collection. |
PUT |
Update information about the attachment (not the binary data). Only the attachment’s entity data can be updated. |
DELETE |
Delete existing attachments. |
Note: To update an actual attachment (the binary data), DELETE the original attachment and POST a new one in the collection.
Actions on attachment instances
Embedded images
Images that you embed in memo fields via REST API are handled the same way as images pasted in the UI: The images are converted to image files. The files are saved in the file repository and referenced from the selected memo field.
The same rules that govern uploading attachments via the UI apply to images posted via REST API.
For example, the command is validated against relevant configuration parameters, such as MAX_ATTACHMENT_COUNT_PER_ENTITY. For details, see Configuration parameters.
See also: