Yes, a put request is roughly equivalent to uploading something via
FTP. You just put the data to some path/uri. Any filename would be in
the uri you're sending the request to. So far as I know, all of the
rest api's in use today just accept a single payload as the body of a
put request, usually XML but which could just as easily be something
like yaml or json. API's wishing to accept file uploads in rest
stylings would likely either just have the data within json/yaml or
have it base64 encoded or maybe binhex'd and stuck in xml as a string.
Additionally, I am unaware of any reason why a put request couldn't
contain multiple payload's by making use of multipart mime, like an
email with an attachment where multipart mime allows both text email
and a file to be conveyed. If using multipart mime, you could supply a
filename in it's headers.
This is the same mechanism used in html forms when uploading files to
provide multiple files and potentially other textual form information
in one payload.
perhaps we should imply PUT by the upload 'somefile.txt' syntax, but
also make use of the Content-Disposition header ( http://www.ietf.org/rfc/rfc2183.txt
) to hint the remote server as to the files original filename, even
though not making use of multipart mime. I believe we should imply the
'post' method when uploading multiple files from a hash of stuff, like
a form, in which case we should be sending that header anyway for each
of the files.
How about this:
upload('somefile.ext', :to => 'http://mysite/action') { |progress| ... }
results in a PUT request with the request body containing the file,
and the standard headers containing a content disposition hinting at
the original filename.
upload({:file1 => open('somefile.ext')}, :to => 'http://mysite/
action') { |progress| ... }
results in a POST request, with multipart mime as the payload (as with
a normal file upload html form) and the same content disposition
headers inside the multipart for each file, regardless of how many
IO's were in the first hash, because even if there is only one file,
many (all?) web frameworks will not be able to decode a non-multipart
request in to the typical hash of keys and values.
If the user wishes to use a different method, let them supply :method
=> 'WHOSITS' in the second hash. We mustn't forget to upcase the
method, people like specifying 'get' and 'post' and server's could
ignore such wrongly cased requests for the sake of processing speed.
On 02/12/2008, at 12:20 PM, e deleflie wrote:
Yes. I've just realised I was a little confused about the difference
between a REST API post and a standard web form POST.
From doing a little research, a REST API post (using the http header
PUT verb) involves putting data typically in XML format in the
payload. I guess that XML will contain both names and values. If
PUT'ing a file, then I am guessing that the file name may be
represented in the URL (or maybe not). Would/could a REST PUT contain
multiple payloads? I dont know (does anyone?)
... so why's suggestion of having both "upload" and "upload_form"
makes sense.
I like shoe's chosen nomenclature of such things as "download" ...
make it very simple for non-technically oriented people to understand
what something does. I was thinking that "post_form" or "submit_form"
would also be very clear (for upload_form) ... but putting oneself in
the shoes (ahem) of the end user is a particular skill, which I am not
sure I can claim to have.
Etienne
