Publishes a data blob

put

https://use.apilookup.for.a.base.url/layers/{layerId}/data/{dataHandle}

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.

Path Params

layerId

string

required

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

dataHandle

string

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 Params

billingTag

string

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.

Body Params

body

Headers

Content-Length

int64

required

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

Content-Encoding

string

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-Type

string

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-Digest

string

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.

Responses

200

OK - Blob was uploaded

401

Unauthorized

403

Forbidden

404

Not Found

409

Conflict - indicates blob with this dataHandle already exists