v1
latestOpenAPI 3.0.12026-07-24110189356.6 KBUploads a part
Upload a single part of a multipart upload for the blob. Every uploaded part except the last one must have a minimum 5 MB of data and maximum of 5 GB, but we do not recommend uploading parts this large. The maximum number of parts is 10,000. Please keep in mind that the actual URL for this operation must be obtained from the response body of start multipart operation that is 'POST /layers/{layerId}/data/{dataHandle}/multiparts' from the 'uploadPart' element under the top level 'links' element of the response.
Path parameters
The ID of the layer that the data blob part belongs to.
The data handle (ID) represents an identifier for the data blob which the part belongs to. The data handle can only contain alphanumeric, '-' and '.' characters, [0-9, a-z, A-Z, -, .]. The maximum length of this field is 600 characters.
The identifier of the multi part upload (token). Content of this parameter must refer to a valid and started multipart upload.
Query parameters
The number of the part for the multi part upload. The numbers of the upload parts must start from 1, be no greater than 10,000 and be consecutive. Parts uploaded with the same partNumber are overridden. Do not reuse the same partnumber when retrying an upload in an error situation (network problems, 4xx or 5xx responses). Reusing the same partnumber in a retry may cause the publication to fail.
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
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.
Size of the entity-body, in bytes. For more information, see RFC 7230, section 3.3.2: Content-Length.
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 - Part was uploaded successfully