To complement the vfs API, it would be nice to have a 'batch' API that works with zip files. e.g.
This would make it much easier to retrieve a bunch of files from a site, or to upload a whole folder (like in USE_PRIVATE_KUDU scenario).
Could we just use Content-Encoding as directive? Using /zip canonical as directive might disallow people with the folder name /zip.
/zip is just the name of the new API, like /vfs, deployments, etc... It can't conflict with any user files.
Got it. In that case, would you need a /zipscm counter part? I still think we could do away with standard http dialect Content-Encoding.
Can we use Accept-Encoding / Content-Type to do this with the vfs API instead?
Reusing the Scm API feels quirky and ambiguous to me. e.g. you may want to actually upload a straight zip file, and you would be entitled to set the content type to zip. So my vote is separate API.
Yup, I agree.
Also it's nicer when you can easily do it from a browser.
Indeed, that's true for the GET side. Basically like our current Dump API, but more generalized.
So this is a special case and only apply to folder such as GET/PUT whole folder (with files) in zip format. This does not apply to PUT/GET individual file.
There is a sample for how to do file upload here: http://aspnet.codeplex.com/SourceControl/changeset/view/bb167f0b0013#Samples/Net45/CS/WebApi/FileUploadSample/Controllers/FileUploadController.cs
The semantic when uploading a zip file is interesting, as there are two possible behaviors:
One option is to use PATCH for (1) and PUT for (2). That seems to match the intended verb semantic.
FWIW, I like the idea of making it “just like HTML file upload” meaning that it should be an HTML file upload form POST. Web API already has great support for dealing with HTML file upload.
That also makes it possible to have additional form post parameters indicating whether existing files should be overridden, what the destination folder should be, etc.
Assigning to Maggie for verification.