| Time |
S |
Nick |
Message |
| 00:37 |
|
|
philbot joined #rest |
| 00:37 |
|
|
Topic for #rest is now #rest REpresentational State Transfer | logs: http://irclog.greptilian.com/rest/today | http://tech.groups.yahoo.com/group/rest-discuss | http://code.google.com/p/implementing-rest/ | http://en.wikipedia.org/wiki/Representational_State_Transfer |
| 00:37 |
|
|
marcoslamuria joined #rest |
| 01:22 |
|
|
blipped joined #rest |
| 01:22 |
|
|
blipped left #rest |
| 02:00 |
|
|
lufi joined #rest |
| 02:53 |
|
dreamdust |
t0astt: POST to /sessions to create a session. use the Authorization header to authenticate requests and return proper 401 or 403's http://stackoverflow.com/questions/7802116/custom-http-authorization-header |
| 02:56 |
|
|
lufi joined #rest |
| 03:13 |
|
|
lufi joined #rest |
| 04:05 |
|
|
lufi joined #rest |
| 04:19 |
|
|
trygvis joined #rest |
| 05:06 |
|
|
fumanchu joined #rest |
| 05:07 |
|
|
vlakarados joined #rest |
| 05:10 |
|
|
Davey joined #rest |
| 05:11 |
|
|
Davey joined #rest |
| 05:29 |
|
|
t0astt left #rest |
| 07:00 |
|
|
lufi joined #rest |
| 07:56 |
|
|
adaro joined #rest |
| 08:54 |
|
|
interop_madness joined #rest |
| 08:56 |
|
interop_madness |
given an XML serialization of a resource, must/should each <link /> have a unique rel-attribute? |
| 09:07 |
|
Jarda |
unique, not |
| 09:07 |
|
Jarda |
think of html for instance, you can have multiple rel="stylesheet" links |
| 09:22 |
|
trygvis |
interop_madness: that is something your hypermedia will tell you |
| 09:22 |
|
trygvis |
if you make your own hypermedia, you can define whatever processing rules you want |
| 09:23 |
|
interop_madness |
ok thanks |
| 09:23 |
|
|
graste joined #rest |
| 09:31 |
|
interop_madness |
Another question: is the "name" parameter of the Content-Disposition header inside a part of a multipart/form-data body mandatory? RFC2388 section 3 defines the parameter as "additional" which i'm not sure means "optional"... |
| 09:32 |
|
trygvis |
how do you nest your multiparts? |
| 09:33 |
|
trygvis |
when a browser sends the data it will use the name parameter to name the data from the <input>'s name attribute so your data is kinda useless without it |
| 09:34 |
|
interop_madness |
trygvis, what do you mean by nesting? each part is delimited by a boundary specified by the "boundary" parameter of the Content-Type request header |
| 09:35 |
|
interop_madness |
trygvis, however the request data does not stem from an input form, so there are no form fields represented in the request |
| 09:35 |
|
interop_madness |
technically it's an abuse of multipart/form-data to solve the "POST metadata along with 0-n content files" problem i mentioned a few days ago... |
| 09:36 |
|
trygvis |
yeah, I guess that :) |
| 09:37 |
|
trygvis |
but if you don't make this look and feel like something like a browser would create I don't see any advantage for you by trying to fake forms |
| 09:37 |
|
trygvis |
the only reason why multipart/form-data is useful is that you can leverage server-side tools |
| 09:38 |
|
trygvis |
if you insist on using multipart you can have your client send two files, one json document and one that is the blob |
| 09:38 |
|
interop_madness |
it can be n blobs though |
| 09:38 |
|
trygvis |
same thing, send an even number of files |
| 09:39 |
|
interop_madness |
so the "name" parameter for the blobs would have to be enumerated in some way: file1, ..., filen |
| 09:39 |
|
interop_madness |
i don't get what even numbers have to do with it |
| 09:40 |
|
trygvis |
I wouldn't use form-data |
| 09:40 |
|
interop_madness |
the cardinality of the parts is completely arbitrary. metadata is optional, but 0-1. files are optional and 0-n |
| 09:42 |
|
interop_madness |
there's also multipart/mixed |
| 09:43 |
|
trygvis |
yes, m/alternate, m/mixed and m/related |
| 09:44 |
|
trygvis |
those are commonly used with html emails |
| 09:44 |
|
trygvis |
there are others too |
| 09:44 |
|
interop_madness |
it's not that i find multipart/* the optimal solution, it's just that i think that any other solution sucks more |
| 09:45 |
|
trygvis |
you could let your payload be a multipart/mixed and let each item in that stream be a multipart/related |
| 09:45 |
|
trygvis |
each of the related pieces would be an optional document with metadata and the optional blob document |
| 09:46 |
|
trygvis |
you'll end up with a kind of tree of documents, like emails are |
| 09:52 |
|
|
Left_Turn joined #rest |
| 09:54 |
|
|
marcoslamuria joined #rest |
| 09:57 |
|
|
rosstuck joined #rest |
| 09:58 |
|
|
lufi joined #rest |
| 10:48 |
|
|
mezod joined #rest |
| 11:13 |
|
|
philbot joined #rest |
| 11:13 |
|
|
Topic for #rest is now #rest REpresentational State Transfer | logs: http://irclog.greptilian.com/rest/today | http://tech.groups.yahoo.com/group/rest-discuss | http://code.google.com/p/implementing-rest/ | http://en.wikipedia.org/wiki/Representational_State_Transfer |
| 11:53 |
|
|
scflode joined #rest |
| 12:48 |
|
|
DrCode joined #rest |
| 12:53 |
|
|
DrCode joined #rest |
| 13:44 |
|
|
nkoza joined #rest |
| 13:49 |
|
|
marcoslamuria joined #rest |
| 13:50 |
|
interop_madness |
what's the most REST-compliant way to pass a filename for a file upload to a REST service? Content-Disposition does not seem to be a good way... |
| 13:50 |
|
interop_madness |
currently i use a custom X-File-Name header with RFC5987 encoded values |
| 14:45 |
|
|
rincewind joined #rest |
| 14:45 |
|
trygvis |
interop_madness: why not Content-Dispotision if you're going the multipart way? |
| 14:47 |
|
interop_madness |
trygvis, i'm fine with Content-Disposition in the multipart case (i use it actually). but my service supports multipart as well as e.g. application/pdf (single file upload). in that case, Content-Disposition is unusual (Content-Disposition is only in the headers of the parts of multipart/form-data) |
| 14:48 |
|
interop_madness |
so if the service needs to support single and multiple files, it seems to be "best practice" that it picks the file name from different headers (e.g. X-FileName for application/pdf, filename param of Content-Disposition for each part of multipart/form-data) |
| 14:50 |
|
|
marcoslamuria joined #rest |
| 15:00 |
|
|
scflode joined #rest |
| 15:04 |
|
trygvis |
can't you just use filename of content-disposition? |
| 15:05 |
|
trygvis |
but you can't call for rest best practices when you know you're forcing it into a strange pattern |
| 15:06 |
|
interop_madness |
i could, but is this a common way of doing it? |
| 15:06 |
|
interop_madness |
that is, if you were to design a REST interface for POST (single file), where would you pass the file name? |
| 15:28 |
|
interop_madness |
trygvis, after much discussion and deliberation, here's what it boils down to: |
| 15:29 |
|
interop_madness |
1. there is no defined way to pass file names in file upload requests in HTTP |
| 15:29 |
|
interop_madness |
2. there is, however Content-Type: multipart/form-data (RFC2388) and RFC2388 requires a Content-Disposition for each part |
| 15:30 |
|
interop_madness |
3. so it would seem natural to have an upload webservice accept only multipart/form-data, even for single files (= 1 part) |
| 15:31 |
|
interop_madness |
4. for convenience for the consumer of said service, single-file uploads can also be done with Content-Type: (whatever) and passing the filename in the Content-Disposition header of the request |
| 15:31 |
|
interop_madness |
5. anyone who frowns upon that, is welcome to use Content-Type: multipart/form-data even for a single file |
| 15:31 |
|
interop_madness |
problem solved. |
| 17:09 |
|
|
mezod joined #rest |
| 17:18 |
|
|
rincewind666 joined #rest |
| 17:47 |
|
|
proteusguy joined #rest |
| 17:56 |
|
|
mezod joined #rest |
| 18:11 |
|
|
tr3online joined #rest |
| 20:48 |
|
|
graste joined #rest |
| 21:59 |
|
|
rincewind_ joined #rest |
| 22:41 |
|
|
proteusguy joined #rest |
