Re: Resumable Uploads

[Carsten Bormann <[e-mail]>]

On Apr 21, 2013, at 04:08, Mark Nottingham <[e-mail]> wrote:

> PUT /foo HTTP/1.1  # create the new resource
> 
> PATCH /foo HTTP/1.1  # start uploading it...
> PATCH /foo HTTP/1.1  # continue...
> ...
> 
> PATCH /foo HTTP/1.1
> Upload-Complete: 1  # we're done!

This is starting to look like draft-ietf-core-block, and is bound to have a number of the same characteristics (except that CoAP blocks are small and fixed-size).
(Of course, -block is solving a different problem...)

How to do this properly probably depends on whether the new resource is freestanding, is bound to be part of a collection, or is an update of an existing resource.

The first PUT may not really create the resource, it might create a temporary that can become the new representation of the resource.
The resource representation is only really completely uploaded with the final patch.

If access to the resource-in-creation is exclusive (e.g., a new URI that is only used by the uploader), the resource can grow in place.
If you don't want to indicate explicitly that it is done, the client can do that implicitly by just starting to use the URI.
Garbage collection (incompletely uploaded resources) is more fun, though.

If access is non-exclusive (multiple clients could be updating it in parallel), you can lock, or you can create an explicit temporary for each uploader, enabling "the last update wins".

Since the original project seems to be about uploading videos, exclusive access is probably the better paradigm.
We don't know if a PATCH (or even the initial PUT) is going to go through completely, so indicating at the start that it is the last one may be impossible.
An explicit close, conditional on the size actually received, may be the best way to do this.
This could use the LINK method or something else.

Grüße, Carsten