You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: src/content/docs/r2/api/workers/workers-api-reference.mdx
+120Lines changed: 120 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -104,6 +104,12 @@ export default {
104
104
- Returns an object representing a multipart upload with the given key and uploadId.
105
105
- The resumeMultipartUpload operation does not perform any checks to ensure the validity of the uploadId, nor does it verify the existence of a corresponding active multipart upload. This is done to minimize latency before being able to call subsequent operations on the `R2MultipartUpload` object.
- Returns an `R2MultipartUploads` containing a list of in-progress multipart uploads in the bucket.
110
+
- The returned list of multipart uploads is ordered lexicographically by key.
111
+
- Refer to [R2ListMultipartUploadsOptions](#r2listmultipartuploadsoptions) for available options.
112
+
107
113
## `R2Object` definition
108
114
109
115
`R2Object` is created when you `PUT` an object into an R2 bucket. `R2Object` represents the metadata of an object based on the information provided by the uploader. Every object that you `PUT` into an R2 bucket will have an `R2Object` created.
@@ -229,6 +235,12 @@ A multipart upload can be completed or aborted at any time, either through the S
229
235
- Completes the multipart upload with the given parts.
230
236
- Returns a Promise that resolves when the complete operation has finished. Once this happens, the object is immediately accessible globally by any subsequent read operation.
- Returns an `R2UploadedParts` containing a list of parts that have been uploaded to this multipart upload.
241
+
- Parts are returned in ascending order by part number.
242
+
- Refer to [R2ListPartsOptions](#r2listpartsoptions) for available options.
243
+
232
244
## Method-specific types
233
245
234
246
### R2GetOptions
@@ -416,6 +428,114 @@ An object containing an `R2Object` array, returned by `BUCKET_BINDING.list()`.
416
428
417
429
- For example, if no prefix is provided and the delimiter is '/', `foo/bar/baz` would return `foo` as a delimited prefix. If `foo/` was passed as a prefix with the same structure and delimiter, `foo/bar` would be returned as a delimited prefix.
- A part number marker that can be passed to future `listParts` calls to resume listing from that point. Only present if truncated is true.
518
+
519
+
### R2UploadedPartInfo
520
+
521
+
An object representing detailed information about an uploaded part.
522
+
523
+
-`partNumber` <Typetext="number" />
524
+
525
+
- The part number of this part.
526
+
527
+
-`etag` <Typetext="string" />
528
+
529
+
- The etag of this part.
530
+
531
+
-`size` <Typetext="number" />
532
+
533
+
- The size of this part in bytes.
534
+
535
+
-`uploaded` <Typetext="Date" />
536
+
537
+
- A Date object representing when this part was uploaded.
538
+
419
539
### Conditional operations
420
540
421
541
You can pass an `R2Conditional` object to `R2GetOptions` and `R2PutOptions`. If the condition check for `get()` fails, the body will not be returned. This will make `get()` have lower latency.
You can list all in-progress multipart uploads in a bucket using the `listMultipartUploads` method. This is useful for managing and cleaning up incomplete uploads.
You can list all parts that have been uploaded to a multipart upload using the `listParts` method. This is useful for resuming uploads or verifying which parts have been uploaded.
The stateful nature of multipart uploads does not easily map to the usage model of Workers, which are inherently stateless. In a normal multipart upload, the multipart upload is usually performed in one continuous execution of the client application. This is different from multipart uploads in a Worker, which will often be completed over multiple invocations of that Worker. This makes state management more challenging.
@@ -274,4 +333,4 @@ To overcome this, the state associated with a multipart upload, namely the `uplo
274
333
275
334
In the example Worker and Python application described in this guide, the state of the multipart upload is tracked in the client application which sends requests to the Worker, with the necessary state contained in each request. Keeping track of the multipart state in the client application enables maximal flexibility and allows for parallel and unordered uploads of each part.
276
335
277
-
When keeping track of this state in the client is impossible, alternative designs can be considered. For example, you could track the `uploadId` and which parts have been uploaded in a Durable Object or other database.
336
+
When keeping track of this state in the client is impossible, alternative designs can be considered. For example, you could track the `uploadId` and which parts have been uploaded in a Durable Object or other database. Alternatively, use `listMultipartUploads` and `listParts` to query the current state of uploads directly from R2.
0 commit comments