Re: Resumable Uploads

[Amos Jeffries <[e-mail]>]

On 20/04/2013 5:02 p.m., Nico Williams wrote:
>
>
> On Apr 19, 2013 5:13 PM, "Martin Thomson" <[e-mail] 
> <mailto:[e-mail]>> wrote:
> >
> > On 19 April 2013 13:56, Daniel Stenberg <[e-mail] 
> <mailto:[e-mail]>> wrote:
> > > I'd just add that a resumed upload does not necessarily imply a 
> previous
> > > upload failure. It could also be that you're appending parts over 
> time as
> > > they "come in" or similar.
> >
> > I'd have thought that this is a perfect fit for PATCH.  Nothing new 
> needed.
>
> Sure, but how do you indicate that a transfer is complete?
>

I would think that any API using PATCH, started with a PUT to create the 
resource, used a series of PATCH to updated it and is treating the 
intermediary stages between initial PUT and followup PATCH's as:

a) time periods when GET on the resource can pull the current state in 
its entirety (no need for a completion signal, as every PATCH makes a 
new "complete" / up-to-date copy)

b) using a final POST to perform resource manipulation through some 
control script - ie copy the final solution to a proper Location, and 
run any post-processing checks.

c) using LOCK/UNLOC requests on theh resource URL explicitly to signaly 
the in-use state across teh period when the resource is being PATCH'd.

And yes, all of these assume working API no problems with a particular 
request/response message. The interesting cases for resume are the ones 
when corruption, loss, or disconnection happen while the server is 
receiving a request.

Amos