On 03/12/2008, at 12:57 PM, Seth Thomas Rasmussen wrote:
On Tue, Dec 2, 2008 at 7:58 PM, e deleflie <[EMAIL PROTECTED]>
wrote:
I like the idea of one method called "upload",
... snip ...
I was just going to put into question Jenna's suggestion of only one
method. The question I was going to ask was ... what is the
advantage,
and to whom for only having 1 method used for 2 different kinds of
posts ...( the "form post" and the "REST post").
I'm not clear on what distinction you see with "form post" versus
"REST post". You can post a form while adhering to REST principles.
Maybe I have a different notion of a form? It seems to me like you are
always posting a form. It might just be one with a single implicit
key/value pair(e.g. upload file, :to => location) as opposed to an
explicit group of them(e.g. upload :fields => { ... }). Again, I don't
know that I have all the concepts clear in my head here.. it doesn't
help to keep talking about post the action and POST the HTTP method..
:P
Okay, imagine the difference between these two files:
"Bob"
and
"name=Bob&happenstance=footware"
One of those has one piece of information, where the other has packed
many pieces of content in to the space of one. Now imagine multipart
mime. A http response has some headers, a blank line, and then
content. Multipart mime works very similarly to that system of email
and http. It is similar in that it provides many pieces of content in
the space of one, except unlike the simple query string form encoding,
multipart mime works almost as though there are several http responses/
emails, with their own headers, each one after the other. They exist
within the body of the email, allowing an email to have the mime/
multipart content-type, and then the client digs deeper, and much as a
zip or tar file would, the message can contain multiple sets of
content. Some may be an attachment and some may be for display (i.e.
text/plain or text/html)
The HTTP method is absolutely irrelevant to the content of the
request, except that some requests, like GET, have no request content.
Nothing says a PUT can't be multipart or that a POST can't have a
single file as it's direct unencoded content. Nothing but convention
that is. You guys are talking an awful lot about REST, but you guys
need to think that through. REST is a relatively new buzzword for
something which is pretty uncommon, and so we should be designing
these api's to work with the internet, and not some over standardized
dystopian future. The fact of the matter is, that if someone is
RESTing, they'll probably be happy enough to explicitly specify the
method, as it is an important implementation detail.
For general use, the web works with GET and POST requests, and all
uploading is done using a POST request with a multipart mime body
which contains each file and also any other form data. On the flip
side, mime is a pain in the butt compared to just sticking data in to
simpler formats like json, zip, xml...
Multipart html form style uploads always need the field name
specified. There is no sensible default for that. So we can either do
something with upload 'somefile.txt', :to => 'wherever' syntax, or
just do nothing with it. Most important is the multipart form uploads.
Perhaps we should expect an IO though, and change the syntax to upload
open('somefile.txt'), :to => 'whereever' for such things, thus, people
could pass in any kind of IO, including pipes, stringio's... good for
streaming. Regardless, rest shouldn't be our focus. Most user's seem
to do stuff like make twitter clients, things which make use of the
existing internet, so don't have the freedom to go around implementing
restyness
Maybe some day we could have http_get/put/post/delete/head style
methods for those who wish to do more low level stuff. Personally
doing more implementation work for some symantics that nobody but me
will ever see has really never appealed to me. So I've never quite
understood the fuss about restful api design.
