#rest on irc.freenode.net 2011-10-25 (txt)

[00:02] grove (~grove@aggw006.cappelendamm.no) joined #rest.
[00:10] KevBurnsJr (~kevburnsj@c-67-169-94-104.hsd1.ca.comcast.net) left irc:
[00:45] grove_ (~grove@aggw006.cappelendamm.no) joined #rest.
[00:46] grove (~grove@aggw006.cappelendamm.no) left irc: Ping timeout: 252 seconds
[00:46] grove_ -> grove
[01:39] Hakon|mbp (~hakon1@228.136.16.62.customer.cdi.no) left irc: Quit: Leaving...
[02:15] Hakon|mbp (~hakon1@22.84-49-55.nextgentel.com) joined #rest.
[02:54] graste (~irc_freen@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[03:01] vmil86 (~vmil86@78.57.245.80) joined #rest.
[03:16] ssedano (~ssedano@unaffiliated/ssedano) joined #rest.
[03:36] HighBit -> HighBit_
[03:39] HighBit_ -> HighBit
[03:43] grove (~grove@aggw006.cappelendamm.no) left irc: Quit: grove
[04:35] mephju (~mephju@dslb-188-102-021-005.pools.arcor-ip.net) joined #rest.
[05:22] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Ping timeout: 252 seconds
[06:42] f00li5h (~f00li5h@unaffiliated/f00li5h) left irc: Ping timeout: 258 seconds
[07:02] bigbluehat (~bigblueha@adsl-74-177-80-83.gsp.bellsouth.net) joined #rest.
[07:09] ramsey (~ramsey@unaffiliated/ramsey) left irc: Excess Flood
[07:10] ramsey (~ramsey@unaffiliated/ramsey) joined #rest.
[07:16] kennethreitz (~kennethre@c-24-127-96-129.hsd1.va.comcast.net) joined #rest.
[07:17] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest.
[07:39] mamund (mamund@obsidian.nullshells.net) joined #rest.
[07:39] #rest: mode change '+o mamund' by ChanServ!ChanServ@services.
[07:40] mamund will be lurking today
[07:41] gchristense (~gchristen@173-166-174-177-washingtondc.hfc.comcastbusiness.net) joined #rest.
[07:42] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Ping timeout: 255 seconds
[07:44] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest.
[07:45] darrel_ waves
[07:45] darrel_ -> darrel
[07:46] mamund does a lurky wave back
[07:47] grahamc (~gchristen@173-166-174-177-washingtondc.hfc.comcastbusiness.net) joined #rest.
[07:48] gchristense (~gchristen@173-166-174-177-washingtondc.hfc.comcastbusiness.net) left irc: Ping timeout: 260 seconds
[07:49] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Ping timeout: 240 seconds
[07:52] Ngarthl hides in the background
[08:01] L0cky (Darren@cpc2-seac19-2-0-cust58.7-2.cable.virginmedia.com) joined #rest.
[08:21] pc1oad1etter (~pc1oad1et@cpe-71-72-121-157.insight.res.rr.com) joined #rest.
[08:34] bigbluehat (~bigblueha@adsl-74-177-80-83.gsp.bellsouth.net) left irc: Quit: Leaving.
[08:44] <whartung> o/ all
[08:45] KevBurnsJr (~KevBurnsJ@50.0.103.34) joined #rest.
[08:45] <darrel> morning!
[08:46] <darrel> whartung: Did you see my attempt to answer the "stale response" question? http://stackoverflow.com/questions/7880280/what-http-status-code-should-i-use-for-a-get-request-that-may-return-stale-data
[08:48] <whartung> yea ok
[08:48] <whartung> certainly not intuitive :)
[08:49] <darrel> I find the all cache-control header stuff really mind bending.
[08:49] <darrel> Especially when you start using it as a request header too.
[08:49] <whartung> I mean, Cache-control: Max-age=0 doesn't that say, effectively, "don't cache this"? Is it interpreted different between a client and a proxy?
[08:50] <darrel> No, that's "no-cache"
[08:50] <darrel> max-age:0 says "this representation is stale, you probably don't want to serve this response from the cache"
[08:53] <KevBurnsJr> morgin!
[08:55] Hakon|mbp (~hakon1@22.84-49-55.nextgentel.com) left irc: Quit: Leaving...
[09:12] <whartung> mojo kennethreitz
[09:12] <whartung> KevBurnsJr:
[09:13] <kennethreitz> whartung: ?
[09:13] <whartung> mis tab kennethreitz
[09:34] mephju (~mephju@dslb-188-102-021-005.pools.arcor-ip.net) left irc: Read error: Connection reset by peer
[09:36] L0cky (Darren@cpc2-seac19-2-0-cust58.7-2.cable.virginmedia.com) left irc:
[09:43] bigbluehat (~bigblueha@adsl-74-177-80-83.gsp.bellsouth.net) joined #rest.
[09:47] Hakon|mbp (~hakon1@228.136.16.62.customer.cdi.no) joined #rest.
[09:59] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left irc: Quit: Leaving.
[10:00] ssedano (~ssedano@unaffiliated/ssedano) left irc: Quit: WeeChat 0.3.4
[10:02] graste (~irc_freen@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[10:05] ssedano (~ssedano@unaffiliated/ssedano) joined #rest.
[10:40] <mikekelly> mamund: I've laid the form guantlet on rest-discuss
[10:40] <mamund> LOL, it was _so_ transparent, too<g>
[10:40] <mikekelly> fancy rehashing the same argument one more time ? :D
[10:40] <mikekelly> seriously though, I would really like someone to come in and explain to me what forms bring to the party in that context
[10:41] <mikekelly> because, afaik, that is _the_ sweet spot for form-like behaviour
[10:41] <mikekelly> so it was troll'ish but it's a serious point.. it needs to be articulated in taht context so dummies like me can 'get it'
[10:43] <mikekelly> I really hope someone does pick that up and explain it..
[10:44] <mamund> actually, i doubt that<g>
[10:44] <mikekelly> why ? :)
[10:45] <mamund> 'cuz you've asked the same thing quite a few times
[10:45] <mikekelly> looking for an answer that makes practical sense..
[10:45] <mamund> yep
[10:45] <mikekelly> maybe I'm too stupid
[10:45] <mikekelly> but the problem is..
[10:45] <mamund> i doubt there is one for you
[10:46] <whartung> I haven't even been following that thread
[10:46] <mikekelly> so is 99% of everyone else
[10:46] <mamund> what would an answer that makes sense look like?
[10:46] <mamund> sound like?
[10:46] <mikekelly> it's hard enough getting people to traverse an application, avoid thinking in terms of object serialization, etc
[10:46] <whartung> I thought we defined a HM client a long time ago...can't quite remember what we said
[10:46] <mamund> what is is that you think 'forms' are 'solving' taht does not make snese?
[10:47] <mikekelly> there has to be a tangible benefit to asking them to dick around with something like forms
[10:47] <mikekelly> otherwise it just wont be used in practice
[10:47] <mamund> and i'm not clear on what a "tangible benefit" will look like
[10:47] <mamund> and not at all convinced that that will be the same in call cases for all devs/users/etc.
[10:48] <mikekelly> mamund: eating into this 'breaking changes' problem without having to version in some way
[10:48] <mamund> this is usually where you and i end up on this one
[10:48] <mamund> ahhh
[10:48] <mikekelly> for *machine clients* btw, not humans
[10:48] <mamund> oh
[10:48] <mikekelly> I don't care about humans, we have html everyone should move on
[10:48] <mamund> no benefit for machine clients if you expect them to "discover and understand" brand new inputs or rels
[10:49] <mikekelly> in which case..
[10:49] <mamund> forms offer no new solutions for macnine clients
[10:49] <mikekelly> ..
[10:49] <mikekelly> :)
[10:49] <mamund> can't recall that i've advocated oterhwsie
[10:49] <mamund> can you?
[10:50] <mikekelly> the implication is that I've rejected some explanation of forms
[10:50] <mikekelly> but you just agreed with me
[10:50] <mikekelly> so I'm sort of confused
[10:50] <mamund> yes, i did
[10:50] <mamund> i have done that before, too<g>
[10:51] <mikekelly> why would you doubt I want someone to enlighten me ?
[10:51] <mamund> well, i can only say that this seems like a re-run to me
[10:51] <mikekelly> I don't have an irrational hatred of forms
[10:51] <mamund> could just be me
[10:52] <mamund> you can i have this convo
[10:52] <mamund> it boils down you your POV that you are only interested in m2m aspects
[10:52] <mamund> i then tell you taht 'forms' offer nothing substantially new for m2m
[10:52] <mamund> and it seems that is the end
[10:52] <mamund> then a few months later
[10:52] <mikekelly> it's re-run because we still have people telling mystical stories about flying spaggeti forms in the super-sonic-evolvable-machine-web-matrix-year-3000
[10:52] <mamund> you ask the same general Q again
[10:52] <mamund> oh
[10:53] <mamund> who would that be?
[10:53] <mamund> me?
[10:53] <mikekelly> it's not general it's pulled into a specific dialogue about evolvability
[10:53] <mikekelly> in which everyone seems agreed that there is a limit to evolvability
[10:53] <mikekelly> but actually no mention of forms at all
[10:53] <mikekelly> so..
[10:54] <mikekelly> given there still seem to be people who think it's a Good Idea to use forms in machine applications.. I'm interested to know what else they bring to the party
[10:54] <mikekelly> because if they bring nothing those people are wasting their (and their clients') time
[10:55] <mikekelly> and the time of anyone dumb enough to listen to rhetoric without actually considering the advice they are recieving
[10:55] <mamund> fwiw, i think you might make a serious dent in this issue if you wrote/posted more about the fallacy
[10:55] <mamund> including examples
[10:55] <mikekelly> that dialogue is a good example as any
[10:55] <mikekelly> I'm not a scientists I hate doing shit like that
[10:56] <mamund> same here
[10:56] <mamund> <>
[10:56] <mikekelly> :)
[10:56] <mikekelly> you don't think pulling forms in at that point, that context, is an effective demonstration ?
[10:56] <mikekelly> pulling them into the conversation I mean
[10:57] <mamund> well, not sure of the context here (continuing to background this thread, actually)
[10:57] <mikekelly> fair enough
[10:57] <mikekelly> I would try to articulate it
[10:57] <mamund> my only suggestion here is that 'asking' for an explantation seems to be 'not working'
[10:58] <mikekelly> I'm pretty sure it has to do with autonomy in some way but I don't know enough about psychology
[10:58] <mamund> so making assertions w/ examples mights change the results
[10:58] <mikekelly> yeah fair enough
[10:58] <mikekelly> I'm a crap scientist
[10:59] mikekelly shrugs
[10:59] <mikekelly> scientists get nothing done anyway, let's be honest..
[10:59] <mikekelly> right that's enough I have to put the kids to bed :D
[11:03] <whartung> There ya go mikekelly , I bit.
[11:03] <whartung> WHAT!!??
[11:03] <whartung> it bouncd my message...piece of junk
[11:04] <whartung> We're writing to let you know that the group you tried to contact (hypermedia-web) may not exist, or you may not have permission to post messages to the group.
[11:04] <whartung> wtf
[11:04] <whartung> was this message cross posted??
[11:05] <whartung> yes it was
[11:05] <whartung> I don't knw what hypermeda-web is
[11:05] <whartung> mk
[11:05] <whartung> fine
[11:10] <darrel> whartung: That's another mailing list that you need to join :-)
[11:10] <whartung> ugh
[11:13] DracoBlue (~Adium@dslb-088-072-029-071.pools.arcor-ip.net) joined #rest.
[11:28] grove (~grove@193.201.9.46.customer.cdi.no) joined #rest.
[11:32] bigbluehat (~bigblueha@adsl-74-177-80-83.gsp.bellsouth.net) left irc: Quit: Leaving.
[11:36] <mikekelly> whartung: I still don't get it
[11:36] <mikekelly> it's probably me.
[11:53] technoweenie (~technowee@host-86-220-9-69.midco.net) joined #rest.
[11:56] <whartung> which part mikekelly
[12:10] <mikekelly> whartung: ITS ON BITCH
[12:17] <darrel> mikekelly: You have to agree though that using forms does give the appearance of less coupling.
[12:27] <mikekelly> only in trivial ways that's my problem with it
[12:28] <mikekelly> i.e. renaming shit (woohoo) and omitting shit (meh)
[12:29] <mikekelly> you can't add shit
[12:29] <mikekelly> be cool if someone did some research into exiting HTTP api's to see what types of interface change occured over time
[12:29] <mikekelly> additions/renamings/removals/breakages
[12:31] <mikekelly> darrel: the problem is the cost of imposing extra requiremetns on clients
[12:33] <mikekelly> if the web was one big theoretical utopia where having the _most_ decoupled application gave you the greatest market share
[12:33] <mikekelly> then fair enough
[12:33] <mikekelly> in the real world most people don't want to cause butthurt for their (potential) clients where it's not necessary, for obvious reasons
[12:35] <mikekelly> it's hard enough to get people to 'dick around' traversing link relations..
[12:36] <darrel> yeah I'd love to see an analysis of types of breaking and non-breaking api changes.
[12:36] <mikekelly> "you have a URI pattern, why is your documentation asking me to 'discover' stuff from an entry point?"
[12:37] <mikekelly> "I can see it's here /widgets/{id} - I'll just use that"
[12:37] <mikekelly> that problem gets 100 times worse with forms
[12:38] <darrel> It's hard enough convincing people to use hypermedia in the first place because of the perceived redundant requests. I can't imagine convincing people to accept this additional layer of indirection.
[12:38] <mikekelly> + the security implications of a client relinquishing control of its state to the server
[12:38] <darrel> eaxctly.
[12:39] <mikekelly> there's so many reasons it's a _horrible_ proposition for clients that I am highly skeptical it has any real world value
[12:39] <mikekelly> it just doesn't buy you enough..
[12:39] <mikekelly> afaict, anyway
[12:42] <technoweenie> i've been struggling with this too. we've been able to keep the GitHub v2 api from breaking except in a few small cases
[12:42] <technoweenie> but thats mostly due to short sighted stuff, like a collection not using pagination
[12:43] <technoweenie> i don't think its that hard to keep a consistent api if the 'style' of it doesn't change
[12:45] <technoweenie> i can't stand how inconsistent the twitter api is. you get calls like statuses/:id/retweeted_by and statuses/retweets/:id
[12:46] <technoweenie> course, we also released a whole new API completely different from v2 (because i couldnt stand how inconsistent it was either)
[12:51] grahamc (~gchristen@173-166-174-177-washingtondc.hfc.comcastbusiness.net) left irc: Changing host
[12:51] grahamc (~gchristen@unaffiliated/grahamc) joined #rest.
[12:53] <darrel> technoweenie: That's why REST api's are supposed to be hypermedia driven so that the server can change it's URI space.
[12:53] <technoweenie> what about what you guys were just talking about
[12:53] <technoweenie> can you just the server to drive
[12:53] <technoweenie> i'm working on a hypermedia client for the new gh api though
[12:54] <darrel> When you tell people this, they dismiss it as crazy talk and yet I hear over and over again the pain that people are suffering because of API changes.
[12:54] <technoweenie> well, its json hypermedia, not sure it makes it 'restful'
[12:55] <darrel> As long as you discover the urls via link relations then the server is free to reorganize it's uri's at any time.
[12:55] <darrel> there is no problem with using JSON as the format for hypermedia media types.
[12:55] <whartung> here's what y'all are missin'.
[12:55] <darrel> e.g. vnd.hal+json
[12:55] <whartung> There are two tenets.
[12:55] <whartung> 1) REST is hard, specifically on the client side. I thnk REST clients are a real PITA. That said...
[12:55] <darrel> I thought there were five!
[12:56] <whartung> 2) a bad client does not invalidate the architecture.
[12:56] <darrel> REST clients are not hard, they are just very different,
[12:56] <technoweenie> well, i hope you guys can tell me why my client sucks when it's ready :)
[12:56] <darrel> LOL
[12:56] <whartung> the fact that someone creates hard coded, path assuming, media type forcing clients doesn't mean that the server by advocating against all of those things is making the wrong choice
[12:57] philipsharp (~Adium@173-166-174-177-washingtondc.hfc.comcastbusiness.net) joined #rest.
[12:57] <whartung> MOST people, processes, and systems DO NOT CARE if the system breaks. They don't mind FIXING such systems on the RARE occasion when they do break.
[12:57] <whartung> so, MOST folks do not create truly flexible REST clients. They're simply not necessary for their use case.
[12:57] ryanhouston (~ryanhoust@173-166-174-177-washingtondc.hfc.comcastbusiness.net) joined #rest.
[12:58] <whartung> The problem is that if you accept the "worst is better meme", then you move in to assuming if all of the clients are going to suck anyway, why put any extra effort in to the server.
[12:58] <whartung> and it's a valid point
[12:58] <darrel> From yesterday.... "I just updated Tekpub in response to some Rug-Pulling gymnastics, courtesy of the Shopify API team and their arrogance" http://wekeroad.com/2011/10/24/a-fun-little-json-murder-mystery-with-ie9
[12:58] <whartung> for small deployments, it's a REALLY valid point. If you have control over both ends of the transaction, who really cares. Do whatever you want
[12:59] DracoBlue (~Adium@dslb-088-072-029-071.pools.arcor-ip.net) left irc: Quit: Leaving.
[12:59] <darrel> Despite the hype, 3rd party API usage in the wild is still in its infancy. The pain is in our future.
[12:59] <whartung> yes it is
[13:00] <technoweenie> " I don't know shit about Ruby. That's your deal."
[13:00] <technoweenie> i integrate w/ a lot of 3rd party apis, i'd be pretty pissed if our chat bot sms paging system broke down because twilio tweaked osmething
[13:00] <darrel> We are the whackos predicting the world will end if people do not change their evil ways.
[13:00] <technoweenie> facebook apparently changes and breaks their shit all teh time
[13:00] <whartung> that's right
[13:00] <pc1oad1etter> Yowza. Today of all days I am interacting with a form from my client for the first time. Maybe I need to read the last few hours of this channel to see if i should even be doing this. :-)
[13:01] <whartung> and facebook is big enough of a "we don't care, we're facebook, we don't have to" that you'll update your clients when they break.
[13:01] <darrel> pc1oad1etter: hehe. It's a personal choice. Mike and I will still talk to you even if you do.
[13:01] <mikekelly> lol
[13:02] <mikekelly> speak for yourself.
[13:02] <darrel> whartung: Exactly. That's why the only people doing EDI are the partners of GM and FORD, etc.
[13:02] <whartung> yup
[13:03] <whartung> You know there are EDI standards for all of those transactions. REams of paper descirbing this, documenting them, specifying them down to the bit positions what to do with them...and there's what Walmart does.
[13:04] philipsharp (~Adium@173-166-174-177-washingtondc.hfc.comcastbusiness.net) left #rest.
[13:06] <mikekelly> technoweenie: for me the main benefit of hypertext is that I can isolate link rels as the one true source of change and liberate my URI space
[13:07] <technoweenie> my experimental api client does that. i like it
[13:07] <mikekelly> yea, I just don't go any further than that
[13:07] <technoweenie> if you're a rubyist: https://github.com/technoweenie/sawyer/blob/master/example/client.rb
[13:07] <mikekelly> i.e. I don't think form-like dynamic studd is practical
[13:07] <mikekelly> I am atm :)
[13:07] <technoweenie> yea i'm experimenting with json schema too
[13:08] mamund is done lurking; toodles!
[13:08] <technoweenie> but i may leave that to a documentation deal. you have to know that the 'foo/bar' relation uses the foo/bar.schema.json file or whatever
[13:08] grove (~grove@193.201.9.46.customer.cdi.no) left irc: Quit: grove
[13:09] <mikekelly> yeah someone is doing that with HAL (in xml though)
[13:10] <technoweenie> i looked at hal, but i wanted something i could layer on my existing api
[13:10] <mikekelly> with a plan to actually expose the schema at the link rel's URI
[13:11] <mikekelly> technoweenie: layer on your api ? that''s what hal's for
[13:11] <mikekelly> .. it's supposed to be anyway
[13:11] <technoweenie> oh, maybe i just dont understand it
[13:12] <technoweenie> you just add those _* properties to your existing json objects then?
[13:12] <mikekelly> it's just a really small media type that has native links and embeddedness
[13:12] <technoweenie> the namespaces are weird
[13:12] <mikekelly> the curies?
[13:13] <technoweenie> yea
[13:13] <mikekelly> that's optional
[13:13] <mikekelly> thinking about removing it completely for json
[13:13] <mikekelly> not really 'in teh spirit' of json
[13:13] <mikekelly> itt's just to avoid having full URIs in teh link rels
[13:13] <mikekelly> tbh you could just define the tokens up front in your docs
[13:14] <technoweenie> yea, i think i'd like that if all it used was _links
[13:14] <mikekelly> well, and _resources
[13:14] <mikekelly> _resources is just a standard way of embedding state
[13:14] <mikekelly> embeddeing other resources*
[13:14] <technoweenie> oh, i just throw them in the json object i guess
[13:14] <mikekelly> right
[13:15] <mikekelly> I'm gonna build a 'browser' for it ove the next month or so
[13:15] <mikekelly> the idea being you could use that to explore any API exposed with hal
[13:15] <mikekelly> be super cool if that was a REPL of some kind :)
[13:17] <mikekelly> sort of like selenium except your building client code
[13:17] <mikekelly> rather than just tests
[13:17] <technoweenie> yuhhhhp i've had the exact same ideas
[13:17] <mikekelly> that'd work a lot well if it was an open media type which is basically the idea behind hal
[13:18] <mikekelly> benefit of the ecosystem dynamic
[13:18] <mikekelly> the idea being that API's differ via their link rels, not by the media type
[13:18] <mikekelly> same thing as HTML
[13:19] <technoweenie> yea, but i'm not changing my api to add _resources. my resources will just have their own _links property
[13:19] <mikekelly> essentially HAL in json is shifting to _links for links and _resources for your embedded resources
[13:21] <mikekelly> technoweenie: out of interest what's the aversion to _resources ?
[13:21] <darrel> mikekelly: I have been playing around with using a RESTAgent instance in a powershell console. It allows me to interactively explore an API.
[13:21] <mikekelly> niiice! :)
[13:22] <darrel> and it transparently deals with hal and html.
[13:22] <technoweenie> two things: 1) i have an existing API and 2) people still write manual clients, so "repo._resources.owner" looks messy
[13:22] <mikekelly> technoweenie: is there a better name for that which woul dbe more appealing?
[13:23] <technoweenie> not really.
[13:24] <technoweenie> im still not sold on _links to be honest
[13:24] <mikekelly> I mean you could change hal in json to rely on determine if an object is an embedded resource or not by checking if it has _links.self
[13:24] <technoweenie> i think i'd like that
[13:26] <Ngarthl> darrel: added an answer to http://stackoverflow.com/questions/7880280/what-http-status-code-should-i-use-for-a-get-request-that-may-return-stale-data
[13:26] <mikekelly> seems more 'bloaty' on the client end to have to do that, is all really
[13:26] <Ngarthl> sorry for cutting in
[13:26] <technoweenie> mikekelly: yea, true *shrug*
[13:27] <mikekelly> technoweenie: that's the driver behind _resources
[13:27] <technoweenie> at any rate, i'll tweak what i'm working on to fit hal better. right now the _links property is an array of objects
[13:27] <technoweenie> not a hash of rel => obj
[13:27] <mikekelly> your clients require JSONPath ?
[13:28] <technoweenie> no
[13:28] <technoweenie> we dont have any official api clients, i assume everyone using teh api is doing something horrible :)
[13:28] <technoweenie> well, brittle
[13:28] <mikekelly> ...
[13:28] <darrel> Ngarthl: Nice. Warning 110 means it is stale. That's cool.
[13:29] <mikekelly> technoweenie: what's your hypothesis on why that is ?
[13:29] <technoweenie> because our latest API is relatively new, and i havent had time to write up an api
[13:29] <technoweenie> i'm hoping when i finish sawyer and start porting it to other languages, the situation will improve
[13:30] <mikekelly> i'm confused about your implementation of _links
[13:30] <mikekelly> if it's an array how does a client find a rel ?
[13:30] <technoweenie> loop through it
[13:30] <mikekelly> until they find the rel they want?
[13:30] <technoweenie> yea
[13:30] <mikekelly> .. isn't that what json objects are for?
[13:31] <mikekelly> sorry to be a dick :P
[13:31] <technoweenie> well, loop through and build a map of them
[13:31] <fu-manchu> but note, Ngarthl, that section says "the *cache* may return...". IMO it's dangerous to apply HTTP cache semantics to a resource that happens to be doing some other kind of caching internally (it may not even be a write-through cache, for example)
[13:31] <technoweenie> mikekelly: i alternated between an array and a hash, but i just said i'll change it to a hash :)
[13:31] <mikekelly> oh sorry I misread I thought you said you wouldn't
[13:31] <technoweenie> ah
[13:31] <mikekelly> my bad :)
[13:32] <mikekelly> and use the link rel as the key right?
[13:32] <technoweenie> yup
[13:32] <technoweenie> i'm still struggling with some of that. should rels have a hierarchy?
[13:32] <technoweenie> rel=user/favorites
[13:32] <technoweenie> i dont know
[13:33] <mikekelly> nah that should be an embedded user rel=user containing a link rel=favourite
[13:33] <Ngarthl> fu-manchu: feel free to improve the answer
[13:33] <fu-manchu> heh :)
[13:33] <fu-manchu> I might
[13:33] <mikekelly> _resources.user.fred._links.favourites
[13:34] <mikekelly> the idea of embedded resources is that they 'reset' the "context URI"
[13:34] <mikekelly> i.e. the subject of the links they contain
[13:35] <technoweenie> ah
[13:35] <mikekelly> technoweenie: is that not appealing in any way?
[13:35] <technoweenie> a little, but not enough to change the whole API
[13:35] <mikekelly> yeah fair enough
[13:35] <mikekelly> ;(
[13:36] <technoweenie> i have other things to think about too
[13:36] <Ngarthl> I want a http aware "object" cache...
[13:36] <mikekelly> lol, me too
[13:36] <technoweenie> for instance, we just added webhooks for every 'event'. every event has a custom payload from the api. so that's yet another potential spot that could break
[13:36] <technoweenie> not just people hitting the api, but the people waiting for pings
[13:36] <technoweenie> i dont want to break someone's CI integration
[13:36] <darrel> Ngarthl: I thought that was mogsie had done?
[13:37] <mikekelly> can't you have people POST mustache with their callback URI ?
[13:37] <mikekelly> I've never understood why people don't do that more
[13:37] <technoweenie> post mustache?
[13:37] <mikekelly> i.e. POST a mustache template
[13:37] <technoweenie> you mean as a way to determine what they expect the payload to look like?
[13:37] <mikekelly> right
[13:37] <technoweenie> {"user":{{name}}}
[13:37] <mikekelly> idd
[13:37] <technoweenie> that's nut lol
[13:37] <technoweenie> i like it... but that sounds like a lot of work too
[13:38] <mikekelly> lol :D
[13:38] <Ngarthl> darrel: builds on my http browser cache. so yeah, he's partly done that. his extension ain't open source though
[13:38] <mikekelly> can't you just wrap the library that's making the webhook event request ?
[13:39] <mikekelly> I said mustache cos it's so well covered language-wise
[13:39] <fu-manchu> speaking of representing the structure of JSON...I wonder if anyone here would be interested in the "JBNF" spec that I wrote for YouGov
[13:39] <Ngarthl> and JBNF is YAA?
[13:39] <Ngarthl> (Yet Another Acronym) ?
[13:39] <Ngarthl> ;)
[13:39] <technoweenie> mikekelly: i can wrap everything
[13:40] <fu-manchu> like ABNF, but a bit higher level; makes it easier to write other media types based on JSON, without having to use e.g. JSONSchema (which is to heavyweight IMO)
[13:40] <fu-manchu> too*
[13:40] Wombert (~Wombert@50.0.103.34) joined #rest.
[13:40] Wombert (~Wombert@50.0.103.34) left irc: Client Quit
[13:40] Wombert (~Wombert@50.0.103.34) joined #rest.
[13:40] <mikekelly> technoweenie: do you have a lot of different webhooks on the go already ?
[13:41] <technoweenie> yea
[13:41] <mikekelly> seems like an additional feature you could phase in
[13:41] <Ngarthl> 'bout time to go to bed here. early morning ahead. toodles
[13:41] <mikekelly> night
[13:42] <mikekelly> technoweenie: i.e. if there's no template submitted and/or possible for the webhook they get it as normal
[13:43] <technoweenie> yea actually this exact case came up. our payload format is a freakin html form post with payload={{json}}
[13:43] <technoweenie> i hate everything about it, but right now you have to specifically turn raw json on :(
[13:44] <technoweenie> i'm trying not to create a ton of work for myself :)
[13:44] <mikekelly> employ me, I'll help
[13:44] <technoweenie> lol
[13:44] <mikekelly> hahaha
[13:44] <mikekelly> I kiid I kiid
[13:45] <mikekelly> seriously, I thikn that would mae webhooks rock
[13:45] <mikekelly> always confused me why nobody does it..
[13:45] <technoweenie> i think everyone would just go with the default
[13:46] <technoweenie> the current setup isnt hard
[13:46] <mikekelly> I guess not - you could stitch up random api's though
[13:46] <mikekelly> as a client of both
[13:47] <mikekelly> that's pretty nifty
[13:47] <technoweenie> oh, thats what the github-services app does. it takes our form/json crap, parses it, and pushes to one of 70 client services
[13:47] <mikekelly> you're the bottleneck for that though, right ?
[13:47] talios (~amrk@akl.smx.co.nz) joined #rest.
[13:48] <technoweenie> yea, but as long as you dont write shit code, i just use the merge button
[13:48] <mikekelly> there's no SERENDIPITOUS REUSE
[13:48] mikekelly fist pumps
[13:48] <mikekelly> can't have a decent rest conversation without dropping that in there
[13:49] <technoweenie> :metal:
[13:50] <mikekelly> technoweenie: so if you have that what was your worry about webhooks again?
[13:50] talios gets scared - join channel and the first thing I see is SERENDIPITOUS REUSE - this is definitely #rest
[13:50] <technoweenie> there are a lot of custom web hooks too, outside of the built-in services
[13:50] <technoweenie> internal apps, build systems, i dont really know
[13:51] darrel all participants of this channel must be SELF DESCRIPTIVE.
[13:51] <talios> HAL no!
[13:51] <talios> I like walks on the beach and....
[13:52] fu-manchu -> fumanchu-dot-ope
[13:53] fumanchu-dot-ope -> fumanchu
[13:53] <fumanchu> bah
[13:53] <fumanchu> we don't have the bandwidth to be self descriptive
[13:53] ryanhouston (~ryanhoust@173-166-174-177-washingtondc.hfc.comcastbusiness.net) left #rest ("Ex-Chat").
[13:56] <darrel> fumanchu: If only headers could be gzipped
[13:59] <talios> just go google spdy:// instead of http :)
[14:02] <mikekelly> mark said we should all stick our awe into spdy
[14:02] <mikekelly> mnot^
[14:02] <darrel> was that awe or oar ?
[14:08] <mikekelly> oar
[14:08] <mikekelly> lol
[14:08] <mikekelly> spelling fail
[14:09] <darrel> oh, that ruined my joke, didn't it.
[14:09] <whartung> I missed it completely
[14:10] <darrel> whartung: Why am I not surprised. :-P
[14:10] <whartung> I never get any of the pop references.
[14:11] <mikekelly> oh right
[14:11] <mikekelly> it's awe?
[14:11] <mikekelly> I thought I was wrong and you were correcting me
[14:12] <whartung> I reserve my awe for the truly....wait for it...awful.
[14:14] <darrel> Speaking of spelling, why does mnot insist on using that nasty acronym and then misspelling it HATEOS.....
[14:16] <mikekelly> good question
[14:19] <darrel> hah. Just say Jan's comment offering to buy him beer if he replaces HATEOS with hypermedia constraint.
[14:25] vmil86 (~vmil86@78.57.245.80) left irc: Read error: Connection reset by peer
[15:07] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) joined #rest.
[15:17] f00li5h (~f00li5h@unaffiliated/f00li5h) joined #rest.
[15:27] jaminja (~jaminja@unaffiliated/jaminja) joined #rest.
[15:53] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) left irc: Ping timeout: 245 seconds
[16:03] bigbluehat (~bigblueha@adsl-74-177-80-83.gsp.bellsouth.net) joined #rest.
[16:04] bigbluehat (~bigblueha@adsl-74-177-80-83.gsp.bellsouth.net) left irc: Remote host closed the connection
[16:38] Wombert (~Wombert@50.0.103.34) left irc: Read error: Connection reset by peer
[16:38] Wombert_ (~Wombert@50.0.103.34) joined #rest.
[17:41] grahamc (~gchristen@unaffiliated/grahamc) left irc: Quit: Leaving...
[18:10] Hakon|mbp (~hakon1@228.136.16.62.customer.cdi.no) left irc: Quit: Leaving...
[18:16] <KevBurnsJr> Womber is visiting. We are about to get drinks.
[18:16] <KevBurnsJr> =D
[18:17] KevBurnsJr (~KevBurnsJ@50.0.103.34) left irc:
[18:17] <darrel> Did he leave the Mustang somewhere safe?
[18:19] Wombert_ (~Wombert@50.0.103.34) left irc: Quit: Wombert_
[18:37] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest.
[19:21] pc1oad1etter (~pc1oad1et@cpe-71-72-121-157.insight.res.rr.com) left irc: Ping timeout: 240 seconds
[19:26] pc1oad1etter (~pc1oad1et@cpe-71-72-121-157.insight.res.rr.com) joined #rest.
[19:49] quest88 (~quest88@c-98-207-205-137.hsd1.ca.comcast.net) joined #rest.
[20:23] technoweenie (~technowee@host-86-220-9-69.midco.net) left irc: Remote host closed the connection
[20:38] darrel_ (~darrelmil@bas3-montreal50-1177637007.dsl.bell.ca) joined #rest.
[20:40] darrel (~darrelmil@bas3-montreal50-1177637007.dsl.bell.ca) left irc: Ping timeout: 252 seconds
[20:53] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Quit: Leaving...
[21:31] agorman (~andy@c-24-130-89-103.hsd1.ca.comcast.net) got netsplit.
[21:37] agorman (~andy@c-24-130-89-103.hsd1.ca.comcast.net) returned to #rest.
[21:41] grove (~grove@193.201.9.46.customer.cdi.no) joined #rest.
[21:44] grove (~grove@193.201.9.46.customer.cdi.no) left irc: Client Quit
[22:07] talios (~amrk@akl.smx.co.nz) left irc: Quit: Bye!
[22:08] jaminja (~jaminja@unaffiliated/jaminja) left irc: Read error: Operation timed out
[22:16] pc1oad1etter (~pc1oad1et@cpe-71-72-121-157.insight.res.rr.com) left irc: Quit: pc1oad1etter
[22:28] grove (~grove@aggw006.cappelendamm.no) joined #rest.
[22:31] jaminja (~jaminja@unaffiliated/jaminja) joined #rest.
[23:32] talios (~talios@ip-118-90-101-1.xdsl.xnet.co.nz) joined #rest.
[23:32] Wombert (~Wombert@guest-client-gate.sfa.network.cynigram.com) joined #rest.
[23:40] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[23:43] Wombert_ (~Wombert@guest-client-gate.sfa.network.cynigram.com) joined #rest.
[23:43] Wombert (~Wombert@guest-client-gate.sfa.network.cynigram.com) left irc: Read error: Connection reset by peer
[23:43] Wombert_ -> Wombert
[23:44] <mogsie> darrel_: And my "object cache" isn't very re-usable. But yes, I think it's a great idea.
[23:54] Wombert (~Wombert@guest-client-gate.sfa.network.cynigram.com) left irc: Read error: Connection reset by peer
[23:54] Wombert (~Wombert@guest-client-gate.sfa.network.cynigram.com) joined #rest.
[23:56] chilversc (~chris@about/csharp/regular/KeeperOfTheSoul) left irc: Quit: leaving
[00:00] --- Wed Oct 26 2011