greptilian logo

IRC log for #rest, 2014-12-22

#rest on freenode has been logged here from May 2014 until end of July 2018 but logging has been suspended because the channel has been riddled with spam since August 2018 with no end in site. See the following blog posts about the problem:

Until the spam problem has been dealt with and logging can resume, please visit our wiki at https://trygvis.io/rest-wiki/

Thanks.

| Channels | #rest index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

All times shown according to UTC.

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

| Channels | #rest index | Today | | Search | Google Search | Plain-Text | plain, newest first | summary

#rest on freenode has been logged here from May 2014 until end of July 2018 but logging has been suspended because the channel has been riddled with spam since August 2018 with no end in site. See the following blog posts about the problem:

Until the spam problem has been dealt with and logging can resume, please visit our wiki at https://trygvis.io/rest-wiki/

Thanks.