[00:54:34] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) joined #rest. [00:56:34] zefer (~zefer@87-194-181-159.bethere.co.uk) joined #rest. [02:57:54] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) left irc: Remote host closed the connection [03:14:12] ssedano (~ssedano@unaffiliated/ssedano) left irc: Quit: WeeChat 0.3.4 [03:54:49] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) joined #rest. [05:25:50] Blazeix (~Blazeix@71.74.190.197) left irc: Quit: woop [05:27:13] Blazeix (~Blazeix@71.74.190.197) joined #rest. [05:53:42] hdave (~hdave@static-71-245-233-130.bstnma.fios.verizon.net) left #rest. [05:55:50] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) left irc: Ping timeout: 252 seconds [06:20:43] Blazeix (~Blazeix@71.74.190.197) left irc: Quit: woop [06:22:34] bigbluehat1 (~bigblueha@adsl-74-177-123-106.gsp.bellsouth.net) joined #rest. [06:27:23] Blazeix (~Blazeix@71.74.190.197) joined #rest. [06:43:26] sbanwart (~sbanwart@66.6.175.18) joined #rest. [06:47:04] Fullmoon (~Fullmoon@dsl-stat-43-17.mmc.at) joined #rest. [06:48:06] Hey, guys. Let's say I have multiple representations of a resource, the most interesting would be json, but there is also a binary representation. Instead of letting the client guess the URL of the binary representation, how should I include it in the response for the JSON response? [06:56:56] Fullmoon: for that particular case, you might consider a link header instead [06:57:40] depends on if you expect the client to store the JSON (without the headers) and yet want to know the URL of the binary later on [06:59:29] otherwise, because bare JSON doesn't have a URL type, you should consider one of the many JSON-based media types (like my own Shoji, if it fits your data ;) or a schema (which would ironically also be linked to from headers, most likely) [07:13:22] Gracenotes (~person@wikipedia/Gracenotes) left irc: Ping timeout: 276 seconds [07:15:00] Action: mamund slides in [07:15:17] Action: darrelmiller waves [07:15:29] o/ [07:16:26] what? at this hour? it's almost beer o'clock! [07:17:07] if only that were true for me [07:18:42] I can still taste the beer from last night. [07:19:17] eww [07:19:54] Gracenotes (~person@wikipedia/Gracenotes) joined #rest. [07:27:19] darrelmiller: btw - really liked your post this AM on the Web API [07:32:15] Yeah, that was a bit of a "doh!" moment for me. [07:32:43] So that's what they have been trying to do. That's why formatter selection is so damn complicated. [07:32:52] yep [07:33:08] IMO, this is where the 'big drift' occurred [07:33:49] Nick change: bigbluehat1 -> bigbluehat [07:33:57] it's just tough to build a 'framework' that doesn't mix the local problem domain model w/ the netowrk protocol model, IMO [07:34:11] +1 [07:34:23] requires very clear SoC and some discipline on the arch and implementation. [07:35:55] and then when you do build it it's got too many knobs and buttons and folks will flock to the framework that *does* mix them, because they don't have to think so hard [07:36:13] fu-manchu: this is also true [07:36:40] most SOAP libraries solve this problem via code-generation of the "bridge" and by actually... [07:36:58] making it very hard to "peek in" to the place where the two meet; essentially... [07:37:20] eliminating the bridge as far as the dev is converned (it's just magice) [07:37:21] I think mixing what formats the client declares support for and what representation formats the server supports into a single negotiation process is a bad idea. [07:37:40] HTTP-* libs have not been successful (or chosen not to do) this [07:39:09] it's tough work, takes some serious brain juice, but i think it's do-able. [07:39:37] i've skteched a few broad ideas, but not tried to do the heavy-lifting needed... [07:39:43] to actually get a working version up and running. [07:39:54] I can prove it's do-able: http://www.cherrypy.org ;) [07:40:54] fu-manchu: That's because python has magic included in the box. [07:40:56] it's been quite a while since i bashed around w/ cherrypy... [07:41:09] darrelmiller: indeed :) [07:41:21] i like the use of templates (that's a big part of good SoC for HTTP, IMO) [07:41:26] I shudder to think what would be involved in porting it to .Net [07:41:43] IIRC, i was not so happy w/ other connect details (mostly header management, i think) [07:41:50] i should spend a bit of time w/ it agtain. [07:44:27] one nice thing we did recently (3.2?) was: we've always had magic deserializers for application/x-www-form-urlencoded, and multipart/form, but then when we added json support we "opened up" the media-type processing code to allow arbitrary processors to be attached (based on the Content-Type) [07:45:17] ahh, yeah. [07:45:31] that _might_ have been a grumble for me in the past; good show! [07:45:32] that's something I'd like to see in an HTTP client, too (if I ever get around to writing one) [07:45:40] yep [07:47:31] pezra (~Adium@webmail.openlogic.com) joined #rest. [07:50:13] fu-manchu: yep, looks like things have changed a bit since my last waltz through cherrypy. [07:50:31] slowly but surely :) [07:50:36] i added it to my list of things to "checkout" sometime soon. [07:50:56] mm-hm. if that's anything like my "reading list" I won't hold my breath :D [07:51:02] LOL [07:51:27] well, it certainly will be _weeks_ not days before i have the proper time. [07:51:41] but, like you say: slowly but surely! [07:59:08] quest88 (~quest88@c-98-207-205-137.hsd1.ca.comcast.net) joined #rest. [08:02:34] having a restful api confuses people [08:05:54] progamming models that challenge the sychronous RPC mindset have an uphill battle [08:06:12] dreinull: +1 [08:06:42] i'm coming to think that Fielding's REST is viewed pretty much the same way as Armstrong's Erlang [08:07:45] the usual complaint from folks when confronted w/ these types of models is "it's too complicated"... [08:07:59] but i suspect a more accurate complaint is "it's too different" [08:08:04] "links make the payload too large" [08:08:26] well, that's just looking for self-satisfiy reasons. [08:08:30] "traversing links to get to the desired resource requires too many roundtrips" [08:08:34] yep [08:08:50] when everything is async, debugging is too hard [08:09:02] I've spent most of my time on #rest topics in SO talking about cache granularity :/ [08:09:09] :) [08:10:55] fu-manchu: The interesting part about that is you can't do resource design without understanding cache granularity and you can't make those decisions without having a solid understanding of the business requireds with regards to data freshness. [08:11:18] ha! which the business usually doesn't know or want to think about [08:11:42] And this ties directly back to overall performance of the application. [08:11:57] well said [08:12:59] Developers are not used to taking such a holistic view of the application. [08:13:14] darrelmiller: yep, i think that is a big part of it [08:13:31] holistic == system-level for me. [08:13:32] yeah, I didn't make any progress on this sort of stuff at my co until I became Chief Architect ;) [08:13:39] ! [08:13:51] Now you carry the big stick :-) [08:13:57] whap! [08:14:04] i've been working on talking about "programming the network" as a way to get folks thinking in new ways [08:15:26] Did you see this tweet https://twitter.com/#!/dehora/status/160331185833254913 [08:15:50] I felt like responding... yeah, they are called hypermedia media types. [08:16:26] amen [08:16:59] it seems like every week now, I tear a chunk of code out of most of our systems by shoving more data into a media-type [08:17:25] fu-manchu: man, i *love* hearing that. [08:17:33] +10 [08:17:38] that is what i tell folks all the time, too. [08:17:54] pull code from clients, and push info into the representation. [08:17:58] very cool to hear that [08:18:03] and 7 times out of 10, that data is just a URI ;) [08:18:10] LOL [08:18:33] an affordance (URI + data-about-the-URI) [08:18:42] right [08:22:27] When I want to return a collection of object (as JSON) to the client, does it make sense, to use the If-Modified-Since header in a way that it either returns a 304 not modifier, or the collection with only the items that were changed since this timestamp? Sounds cool to me [08:23:16] I like the rest idea but I find plain old html limited to deal with it in a ux friendly way. [08:27:22] Or if not, what is a good idea for this kind of "I have this set of resource that were up-to-date at jan 20, 8:14am, give me a list of resources that were updated since then" [08:30:04] Fullmoon: the least complicated pattern is to use etags on the resource. [08:30:15] and make sure clients honor them. [08:47:05] or use Atom [09:02:13] dreinull (~dreieins@217.18.70.225) left irc: Ping timeout: 248 seconds [09:08:31] fu-manchu (~fumanchu@adsl-99-30-180-185.dsl.sfldmi.sbcglobal.net) left irc: Ping timeout: 252 seconds [09:08:44] fu-manchu (~fumanchu@99.30.180.185) joined #rest. [09:09:24] Thanks. [09:09:27] quest88 (~quest88@c-98-207-205-137.hsd1.ca.comcast.net) left irc: Quit: quest88 [09:09:30] np [09:09:36] good to see you hare [09:09:41] s/hare/here [09:09:42] [09:10:13] don't mind mamund, he has a rabbit fetish. It sneaks out at times. [09:10:28] And, lastly, let's say I return a collection of resources, and want to signal to the client that there are "more" resource, preferably with an URL, what is a good way to do this? [09:10:45] *that there is more to get [09:10:58] Just recommend me a good book, guys ;) [09:10:58] that's done with a link with a rel like "more" or something. [09:11:02] or "next" [09:11:03] provide links [09:11:23] yep, there are some registered link-rels for this,too. [09:11:37] check the IANA list [09:12:02] http://www.iana.org/assignments/link-relations/link-relations.xml [09:12:18] mamund: Very nice, looks exactly like what I want.. [09:12:25] {"link" : {"rel" : "next", "href" : "..."} [09:12:34] {"link" : {"rel" : "next", "href" : "..."}} [09:12:56] Just got a recommendation for O'reily RESTful Web Services [09:13:07] that's a good starter book. [09:13:27] also consider RESTful Web Services Cookbook by subbu allamaraju [09:14:10] yea those are both good [09:14:15] I may even own them :) [09:14:33] so, this opinion might actually be based on actual experience. [09:14:35] but I forget. [09:15:16] whartung: You mean all the time? [09:15:36] also look into REST in Practice (webber, robinson, parastiditis) [09:15:44] huh? what? Who are you people. [09:15:57] GET OUT OF MY BEDROOM! [09:16:08] Action: mamund is now officially creeped out [09:16:24] what, I have a t-shirt on. [09:16:40] Action: mamund shudders and looks at the ceiling [09:17:28] http://code.google.com/p/implementing-rest/wiki/Books [09:17:42] Fullmoon: check out the implementing REST wiki, too. [09:17:50] Action: mamund notes we should proly update that book list [09:17:59] mamund: I shall, thanks. [09:18:04] np [09:19:06] zefer (~zefer@87-194-181-159.bethere.co.uk) left irc: Quit: zefer [09:40:34] dreinull (~dreieins@217.18.70.225) joined #rest. [09:47:18] Fullmoon (~Fullmoon@dsl-stat-43-17.mmc.at) left irc: Quit: Fullmoon [09:58:02] hdave (~hdave@static-71-245-233-130.bstnma.fios.verizon.net) joined #rest. [10:00:44] dreinull (~dreieins@217.18.70.225) left irc: Ping timeout: 240 seconds [10:02:14] dreinull (dreieins@217.18.70.225) joined #rest. [10:41:19] o hai [10:41:28] fu-manchu: summoned [10:42:56] KevBurnsJr: o/ [10:51:33] mamund: \0 [10:51:47] KevBurnsJr: \o\ [10:51:48] mamund: apparently I'm wearing a ski mask [10:51:54] ahhh [10:52:12] also good morning [10:52:27] i will be in SF most of next week. [10:52:38] Fullmoon (~Fullmoon@dsl-stat-43-17.mmc.at) joined #rest. [10:53:41] ideazinf (~ideaz@12.104.148.2) joined #rest. [10:57:17] Fullmoon (~Fullmoon@dsl-stat-43-17.mmc.at) left irc: Remote host closed the connection [10:57:21] OH RLY [10:57:40] our CTO is opening for Morgan Page on Saturday [10:57:52] ?!@#? [10:57:53] We've got a VIP table with your name on it if you're in town [10:57:57] ideaz (~ideaz@12.104.144.2) left irc: Ping timeout: 248 seconds [10:58:25] darrelmiller: remember that song "In the air"? That's Morgan Page. [10:59:32] i land @ SFO monday noon and leave SFO friday 7AM [11:00:27] where are you staying? [11:00:52] 10 hallam downtown, close to the Atlassian offices, i think. [11:01:10] near the UN plaza? [11:02:58] KevBurnsJr: the URI RFC uses "URI" for your "Absolute URI" and "relative-ref" for your root/path relative URI's [11:05:28] and special "path-noscheme" etc to differentiate relative-refs [11:34:22] kevBurnsJr: I do remember. Nice. [11:57:06] phidah (~phidah@x1-6-e0-46-9a-98-00-b2.k1053.webspeed.dk) joined #rest. [11:57:10] phidah (~phidah@x1-6-e0-46-9a-98-00-b2.k1053.webspeed.dk) left #rest. [11:58:05] phidah (~phidah@x1-6-e0-46-9a-98-00-b2.k1053.webspeed.dk) joined #rest. [11:59:42] I have an application that is to receive a data matrix via a REST api. The data has two dimensions: unit and period - and then a number for each combination (some are blank though). [12:00:22] How would that best be transmitted….? A POST array (data[unit_id][period_id] = xx) ? [12:00:33] XML/JSON POST to the server? [12:00:58] I would certainly consider a nested JSON array, yes [12:06:08] fu-manchu: Would the POST-array be a viable alternative or is the best practice to use the json array? [12:06:37] I guess I would then be forced to support XML as well since I do that on the read stuff in the API [12:07:43] by "POST array" I assume you mean application/x-www-form-urlencoded? [12:08:07] that might have a larger base of servers which understand it [12:49:14] Action: mamund is leaving now; carry on [13:04:22] sbanwart (~sbanwart@66.6.175.18) left irc: Ping timeout: 276 seconds [13:12:09] fu-manchu: cool, thx [13:13:01] Action: KevBurnsJr reads 3986 - http://tools.ietf.org/html/rfc3986 [13:19:44] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) joined #rest. [14:02:16] mamund: no way, that's like half a block from my new place [14:02:50] 123 langton st san francisco ca 94103 [14:03:19] you're a stones throw from Bloodhound, City Beer and Brainwash [14:15:13] In fact, Bloodhound is half the bottom floor of your hotel. [14:15:53] I've been to Github and riak drinkups at Bloodhound. [14:35:10] bigbluehat (~bigblueha@adsl-74-177-123-106.gsp.bellsouth.net) left irc: Quit: Leaving. [14:47:51] dreinull (dreieins@217.18.70.225) left irc: Ping timeout: 248 seconds [14:48:36] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) left irc: Quit: Leaving... [16:29:28] dreinull (dreieins@217.18.70.225) joined #rest. [16:31:44] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) joined #rest. [16:32:47] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) left irc: Client Quit [16:36:05] pezra (~Adium@webmail.openlogic.com) left irc: Quit: Leaving. [16:38:59] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) joined #rest. [16:39:20] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) left irc: Client Quit [16:54:53] phidah (~phidah@x1-6-e0-46-9a-98-00-b2.k1053.webspeed.dk) left irc: Quit: phidah [16:56:37] dreinull (dreieins@217.18.70.225) left irc: Ping timeout: 252 seconds [17:38:21] bigbluehat (~bigblueha@adsl-74-177-123-106.gsp.bellsouth.net) joined #rest. [18:46:29] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) joined #rest. [18:58:05] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) left irc: Quit: Leaving... [20:18:06] KevBurnsJr (~KevBurnsW@50.0.103.39) left irc: [20:18:47] bigbluehat (~bigblueha@adsl-74-177-123-106.gsp.bellsouth.net) left irc: Quit: Leaving. [20:43:04] fu-manchu (~fumanchu@99.30.180.185) left irc: Ping timeout: 272 seconds [00:00:00] --- Sat Jan 21 2012