#rest on irc.freenode.net 2012-01-20 (txt)

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