On Mon, Dec 1, 2008 at 9:13 PM, Jenna Fox <[EMAIL PROTECTED]> wrote: > 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.
I like the idea of one method called "upload", but I don't think there should be any implied HTTP method unless you could detect if the URI you were pointing to exists on the server already or not because the difference between a PUT and a POST is all about what you are doing to the resource, right? If the URI didn't previously exist, it would be a POST because you are creating. If you were updating something already there, it would be a PUT for an update. That said, I could see POST being the default, but that's partly just my web background biasing my views again. I understand, too, that there is a tool or two out there which flips the semantics of POST and PUT around, but I think the way I understand it is more popular and catching on more in these modern times. -- Seth Thomas Rasmussen http://greatseth.com
