Sign in

v1

latestOpenAPI 3.0.12026-07-24110189356.6 KB
blob

Publishes a data blob

Persists the data blob in the underlying storage mechanism (volume). Use this upload mechanism for blobs smaller than 50 MB. The size limit for blobs uploaded this way is 5 GB but we do not recommend uploading blobs this large with this method, so use multipart upload instead. When the operation completes successfully there is no guarantee that the data blob will be immediately available although in most cases it will be. To check if the data blob is available use the HEAD method.

put/layers/{layerId}/data/{dataHandle}

Path parameters

layerIdstring required

The ID of the layer that the data blob belongs to.

dataHandlestring required

The data handle (ID) represents an identifier for the data blob. The data handle can only contain alphanumeric, '-' and '.' characters, [0-9, a-z, A-Z, -, .]. The maximum length of this field is 600 characters.

Query parameters

billingTagstring

Billing Tag is an optional free-form tag which is used for grouping billing records together. If supplied, it must be between 4 - 16 characters, contain only alpha/numeric ASCII characters [A-Za-z0-9]. Grouping billing records by billing tag will be available in future releases.

Headers

Content-Lengthinteger required

Size of the entity-body, in bytes. For more information, see RFC 7230, section 3.3.2: Content-Length.

Content-Encodingstring

Specifies what content encodings have been applied to the blob and thus what decoding mechanisms must be applied to obtain the media-type referenced by the Content-Type header field. If the 'contentEncoding' field is specified in the catalog layer configuration this value must be equal to it. For more information, see RFC 7231, section 3.1.2.1.'

Content-Typestring required

A standard MIME type describing the format of the blob data. For more information, see RFC 2616, section 14.17: Content-Type. The value of this header must match the content type specified in the 'contentType' field when the multipart upload was initialized, and this content type must also match the content type specified in the layer's configuration.

X-HERE-Digeststring

This header can be used as a data integrity check to verify that the data received by the server is the same data that was originally sent by the client. This header specifies the lowercase Hex encoded 32-bit CRC32C checksum of the object or 128-bit MD5 digest or 160-bit SHA1 digest or 256-bit SHA256 digest. You can choose one of the following Secure Hash Algorithms (SHA) or Cyclic Redundancy Check (CRC) checksum algorithms to calculate the digest value:

  • CRC-32C
  • MD5
  • SHA1
  • SHA256

Value of the header is a combination algorithm name and digest in following format: "Algorithm:Digest". If the digest values calculated on the client side doesn't match to the digest on the server side, server generates Bad Request error.

Response

OK - Blob was uploaded