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

[00:09] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[00:11] brainproxy (~brainprox@pdpc/supporter/gold/brainproxy) joined #rest.
[00:13] <brainproxy> anyone recommend an academic paper or other write-up which explore REST from perspective of functional programming?
[00:13] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) left irc: Quit: Leaving...
[00:28] DracoBlue1 (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[00:28] DracoBlue1 (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[00:30] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left irc: Ping timeout: 248 seconds
[00:41] <talios> brainproxy - havn't seen any, did you find any?
[00:43] Hakon|mbp (~hakon1@130.82-134-26.bkkb.no) joined #rest.
[00:43] <talios> what would said paper address exactly tho? I was looking at the restas framework yesterday ( http://restas.lisper.ru/en/tutorial/hello-world.html ) for Common Lisp, light weight web framework that feels at a level suited to REST
[01:22] <talios> Quiet in here at this hour isn't it.
[01:23] <trygvis> brainproxy: I don't see the relation to be honest
[01:24] <trygvis> I've done a lot of functional programming, but it's not really related to what you put on the wire
[01:24] <talios> The only correlation I could see, which actually puts FP in a good standing with REST would be the no-shared-state mentality.
[01:25] <trygvis> right, there's a lot of those similarities but not really a research topic as I can see :)
[01:25] <talios> but thats a vague link at best
[01:26] <trygvis> there's also the fact that some function languages have a focus on pure vs unpure which is important in REST
[01:26] <talios> I keep having the thought that when going down the HATEOAS route - resources MUST be immutable. Changes can ONLY occur thru state-change. Not blanket mutation.
[01:26] <trygvis> working with HTTP and just mapping/folding/zipping/splitting the result is super easy
[01:27] <trygvis> no blanket mutation sure, but they're perfectly mutable. you just got to make sure that the client is told how to do it
[01:28] <talios> i.e. "PUT a price-change-request for $2" rather than "product.price=2"
[01:28] <talios> true.
[01:28] caaakeeey (~caaakeeey@gatekeeper-ext.zeus.com) joined #rest.
[01:28] <trygvis> isn'
[01:28] <trygvis> isn't the latter just a way to serialize the first?
[01:29] <trygvis> but I see your point, no direct object mutation. better send commands and have the server process them
[01:30] <talios> not really - the former includes -intent-. what we have in some of our system current lets us do say "product.price=2 & product.description=something", which means the server needs to guess your intent
[01:30] <talios> with a "price change", you're declaring your intent to change a price, and ONLY a price.
[01:31] <talios> imho, a "price change" also implies some form of business process, that might have side effects.
[01:31] <talios> but well known side effects
[01:32] <trygvis> sure, but I think I would end up with a *serialization* based on www-form-urlencoded for that kind of operation
[01:32] <trygvis> the server can always deny the operataion by saying bad request or something
[01:33] <talios> yep. my thinking is to push my calls more towards doing "one thing at a time", rather than the potential of n-things all at once.
[01:35] <trygvis> hm, I don't see the problem with having "bigger" operations. it all depend on your app/domain/business really
[01:35] <trygvis> sometimes it's needed to get the transaction scope correct
[01:36] <caaakeeey> trygvis, batch operations can be very useful, for example mobile use with intermittent connectivity to the internet - you want to still allow ther user to use the app, and then sync with the server at an appropriate time, while keeping the operations themseleves separate
[01:36] <talios> certainly makes for auditing what happened much easier - or more, WHY it happened. i.e. the closing of a users account, knowing that it was "closed", "cancelled", "banned" is important. but thats much more "our business requirement" than anything
[01:37] <talios> caaakeeey - batches of operations++ one operation all mashed into one tho?
[01:37] <trygvis> caaakeeey: sure, but that's something that has to be done on a higher level even if you leverage REST
[01:37] <talios> same reason us coders tend to like small commits to source control over one HUGE merge.
[01:38] <caaakeeey> in the sense theres only one request, but its really just a helper multiplexer on both ends to avoid a number of requests - its still split into smaller operations
[01:38] <caaakeeey> so i guess im agreeing with you
[01:38] <caaakeeey> even big operations should be split up
[01:38] <trygvis> general statements like that is not very useful
[01:39] <talios> what do you think about POSTING a multipart/mixed with multiple requests? :)
[01:40] <talios> transactional :)
[01:40] <trygvis> you'll get some caching challenges at least
[01:41] <trygvis> it's doable, you just need to know the potential downsides by updating stuff sideways
[01:41] <talios> clients shouldn't be caching based on POST anyway IMHO
[01:41] <caaakeeey> trygvis, caching not really an issue, as they come in order, so the only thing you're hiding is they technically should have been multipel requests
[01:42] <trygvis> talios: they might have been allowed to cache GET /a, but if you update /a by posting to /updates intermediates can't know that /a is outdated
[01:42] <trygvis> it can be "fixed" by setting must-revalidate on /a, but then you're increasing network traffic
[01:43] <talios> trygvis - if you're doing that when you should also mandate e-tags, If-Modified-Since, If-Match stuff as well - that should solve that
[01:44] <trygvis> yep
[01:44] <talios> mind you - if you've POSTed a change for /a, you could expire your own local cache copy
[01:44] <trygvis> actually I think that's a MUST
[01:44] <talios> +1
[01:44] <caaakeeey> talios, doesn't sovle every other client with a cached copy
[01:45] <trygvis> but if you've updated /a through /updates your local cache can't know that
[01:45] <trygvis> and then you can suddenly be up shit creek
[01:45] <talios> caaakeeey: true, but that would also be a product if client a POSTED to /a and client b had a cache
[01:45] <talios> prodblem even
[01:46] <trygvis> but these solutions are all a bit silly without discussing a bit more specific kind of REST application
[01:46] <caaakeeey> well in the case of the mobile app, we realised that unlike the web app, people were more interested in personal data, and so cache invalidation was far less likely to be an issue
[01:47] <trygvis> sounds reasonable
[01:48] <trygvis> just make sure that you start with a personal feed with *links* to global resources :)
[01:48] <talios> i suppose with personal data on a mobile app - the mobile user is more likely to be the only one updatig their data as well
[01:49] <talios> mmm links - that reminds me. I'm supposed to be writing up another HATEOAS rant blog on linking, to go with my 2 former ones/
[01:49] <caaakeeey> talios, yeah basically
[01:50] <trygvis> talios: got a *link* to your blog? :P
[01:50] <talios> trygvis: http://theoryinpractise.tumblr.com/post/14843929966/practical-hateoas-pimping-geekzone-part-1 is my first HATEOAS post. My normal blog kinda got deleted as a server so using the tumbler more ow.
[01:50] <talios> now.
[01:51] <talios> must move that to the new domain as well, with the -correct- spelling of practice, since EVERYONE complains ;p
[01:54] <talios> I've not had any flame retorts from other rest nazi's so thats a good sign.
[01:54] <mk_> talios: that's a good blog post, nice one
[01:54] <talios> http://theoryinpractise.tumblr.com/post/15235387762/practical-hateoas-part-2-content-negotiation was the followup, based on the comment I got
[01:55] <trygvis> I like the MUD analogy
[01:56] <talios> I love to write a MUD REST client.
[01:56] <talios> that just navigated resources.
[01:56] <trygvis> you might want to look at mamund's maze
[01:57] talios hits the google - oo. that sounds interesting.
[01:58] <trygvis> lunch!
[01:59] <talios> at 11pm! madness. but good call - munchies!
[02:12] burngreg (~greg@121.98.184.176) left #rest.
[02:31] kennethreitz (~kennethre@173-13-176-158-sfba.hfc.comcastbusiness.net) joined #rest.
[02:34] <trygvis> yum
[02:41] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[02:42] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[03:05] talios (~textual@ip-118-90-11-129.xdsl.xnet.co.nz) left irc: Quit: Textual IRC Client: http://www.textualapp.com/
[03:34] mephju (~mephju@dslb-188-103-176-213.pools.arcor-ip.net) joined #rest.
[04:08] Wombert (~Wombert@dslb-092-075-003-110.pools.arcor-ip.net) left irc: Quit: Wombert
[04:28] kennethreitz (~kennethre@173-13-176-158-sfba.hfc.comcastbusiness.net) left irc: Quit: Computer has gone to sleep.
[04:49] Split (~split@84.34.147.60) left irc: Ping timeout: 240 seconds
[04:51] Split (~split@84.34.147.60) joined #rest.
[05:17] Wombert (~Wombert@89.204.154.97) joined #rest.
[05:21] Wombert (~Wombert@89.204.154.97) left irc: Ping timeout: 240 seconds
[05:25] grove (~grove@aggw006.cappelendamm.no) joined #rest.
[05:29] Wombert (~Wombert@89.204.154.97) joined #rest.
[05:35] Wombert (~Wombert@89.204.154.97) left irc: Quit: Wombert
[05:57] <mk_> well this didn't clear anything up for me at all https://twitter.com/#!/Paul_Kinlan/status/157252269409177600
[05:58] <saml> mk_, what was original question?
[05:59] <mk_> https://twitter.com/#!/mikekelly85/status/157136242583154688
[05:59] <saml> what's web intent?
[05:59] <mk_> http://webintents.org/
[06:00] <mk_> I'm not 100% sure
[06:00] <mk_> :)
[06:06] grove (~grove@aggw006.cappelendamm.no) left irc: Quit: grove
[06:17] pezra (~Adium@webmail.openlogic.com) joined #rest.
[06:26] bigbluehat (~bigblueha@nmd.sbx08595.greensc.wayport.net) joined #rest.
[06:46] aGHz1 (~Adium@modemcable153.0-178-173.mc.videotron.ca) joined #rest.
[06:46] aGHz (~Adium@modemcable153.0-178-173.mc.videotron.ca) left irc: Ping timeout: 244 seconds
[06:48] mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) joined #rest.
[07:04] grove (~grove@84.115.45.31.customer.cdi.no) joined #rest.
[07:05] grove (~grove@84.115.45.31.customer.cdi.no) left irc: Client Quit
[07:08] Hakon|mbp (~hakon1@130.82-134-26.bkkb.no) left irc: Quit: Leaving...
[07:13] <fu-manchu> wow that's 2 SO #rest questions I answered first this morning. darrelmiller must be actually hard at work today
[07:15] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[07:15] bigbluehat (~bigblueha@nmd.sbx08595.greensc.wayport.net) left irc: Quit: Leaving.
[07:16] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[07:25] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[07:26] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left irc: Client Quit
[07:42] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[07:42] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[07:51] mephju (~mephju@dslb-188-103-176-213.pools.arcor-ip.net) left irc: Quit: Ex-Chat
[07:58] Hakon|mbp (~hakon1@85.200.216.142) joined #rest.
[07:59] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[08:05] mhausenblas (~mhausenbl@wlan-nat.fwgal01.deri.ie) left irc: Quit: brb
[08:19] Hakon|mbp (~hakon1@85.200.216.142) left irc: Quit: Leaving...
[08:27] bigbluehat (~bigblueha@nmd.sbx08595.greensc.wayport.net) joined #rest.
[08:31] DracoBlue (~Adium@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[08:41] bigbluehat (~bigblueha@nmd.sbx08595.greensc.wayport.net) left irc: Quit: Leaving.
[08:45] aGHz1 -> aGHz
[08:58] pezra (~Adium@webmail.openlogic.com) left irc: Quit: Leaving.
[09:00] pezra1 (~Adium@webmail.openlogic.com) joined #rest.
[09:15] KevBurnsJr (~KevBurnsW@50.0.103.39) joined #rest.
[09:27] kennethreitz (~kennethre@173-13-176-158-sfba.hfc.comcastbusiness.net) joined #rest.
[10:00] <darrelmiller> fu-manchu: I had to go to a customer to remove a f*cking virus off a PC. ...and I failed.
[10:00] <fu-manchu> :(
[10:01] fu-manchu has almost forgotten what a "PC" is
[10:01] <whartung> no, they failed, you just put a stake in the vampire
[10:03] <darrelmiller> I tell you, we live in a different world than the average small business. So many of them haven't changed in 5-7 years.
[10:05] <fu-manchu> I don't blame them
[10:13] <darrelmiller> fu-manchu: Yeah, the versioning question came up again. I do so love that debate....... :-\
[10:17] dkubb (~dkubb@50.92.131.237) left irc: Quit: Linkinus - http://linkinus.com
[11:05] caaakeeey (~caaakeeey@gatekeeper-ext.zeus.com) left irc: Quit: Leaving
[11:12] bigbluehat (~bigblueha@adsl-98-71-138-222.gsp.bellsouth.net) joined #rest.
[11:22] pezra1 (~Adium@webmail.openlogic.com) left irc: Quit: Leaving.
[11:53] pezra (~Adium@webmail.openlogic.com) joined #rest.
[11:57] kennethreitz (~kennethre@173-13-176-158-sfba.hfc.comcastbusiness.net) left irc: Quit: Computer has gone to sleep.
[13:06] kennethreitz (~kennethre@204.14.152.118) joined #rest.
[14:01] saml (~sam@adfb12c6.cst.lightpath.net) left irc: Quit: Leaving
[14:07] Hakon|mbp (~hakon1@193.137.202.84.customer.cdi.no) joined #rest.
[14:08] bigbluehat (~bigblueha@adsl-98-71-138-222.gsp.bellsouth.net) left irc: Quit: Leaving.
[15:35] dreinull (~dreinull@ip-78-94-220-161.unitymediagroup.de) left irc: Remote host closed the connection
[15:48] Wombert (~Wombert@xdsl-78-35-206-172.netcologne.de) joined #rest.
[16:03] Wombert (~Wombert@xdsl-78-35-206-172.netcologne.de) left irc: Quit: Wombert
[16:04] Wombert (~Wombert@xdsl-78-35-206-172.netcologne.de) joined #rest.
[16:05] Wombert (~Wombert@xdsl-78-35-206-172.netcologne.de) left irc: Client Quit
[16:17] pezra (~Adium@webmail.openlogic.com) left irc: Quit: Leaving.
[16:54] KevBurnsJr_ (~KevBurnsW@50.0.103.39) joined #rest.
[17:03] KevBurnsJr (~KevBurnsW@50.0.103.39) got netsplit.
[17:03] ssedano (~ssedano@unaffiliated/ssedano) got netsplit.
[17:10] ssedano (~ssedano@unaffiliated/ssedano) returned to #rest.
[17:14] KevBurnsJr (~KevBurnsW@50.0.103.39) got lost in the net-split.
[17:50] quest88 (~quest88@c-98-207-205-137.hsd1.ca.comcast.net) joined #rest.
[18:01] talios (~textual@akl.smx.co.nz) joined #rest.
[18:11] KevBurnsJr_ (~KevBurnsW@50.0.103.39) left irc:
[19:14] dkubb (~dkubb@50.92.131.237) joined #rest.
[19:24] <darrelmiller> hDave1: Out of curiosity, do you know who Michael Kay is? (the guy who answered your XML question on SO)
[19:25] kennethreitz (~kennethre@204.14.152.118) left irc: Quit: Computer has gone to sleep.
[19:25] <hdave1> darrelmiller: I don't
[19:26] <darrelmiller> http://en.wikipedia.org/wiki/Michael_Kay_(software_engineer)
[19:26] <darrelmiller> I'd say he can give you a pretty authoritative answer on anything XML related :-)
[19:27] <hdave1> LMAO
[19:27] <hdave1> what is his SO name?
[19:28] <darrelmiller> http://stackoverflow.com/users/415448/michael-kay
[19:28] <hdave1> I can't find the question he gave an answer too...
[19:28] <hdave1> tthanks
[19:28] <darrelmiller> http://stackoverflow.com/questions/8841724/is-there-practically-a-11-correspondence-between-an-xml-schema-and-an-xml-nam
[19:28] <hdave1> i hate that question...
[19:29] <hdave1> i was having a lot of trouble trying to ask the right question....
[19:29] <hdave1> i didn't get it right
[19:29] <hdave1> the real question is this
[19:30] <hdave1> i have a problem with looking into the XML payload of a REST response to get the namespace URL and from that interpreting the XML
[19:30] <darrelmiller> Just to stir the pot. I avoid namespaces in XML almost completely.
[19:30] <hdave1> oh boy... !
[19:30] <hdave1> i want the media type to fully describe the thing
[19:30] <darrelmiller> hdave1: And so you should have a problem with doing that :-)
[19:30] <darrelmiller> exactly.
[19:31] <hdave1> ok, but then, adding a version parameter to a media type some time in the future is a certainly
[19:31] <darrelmiller> This is good reading: http://blog.jclark.com/2010/01/xml-namespaces.html
[19:31] <hdave1> s/certainly/certainty
[19:31] <hdave1> i don't mind versioning media types....i don't plan on making it a habit...
[19:32] <hdave1> i could see have 3,4,5 version of the course of 5-7 years
[19:32] <hdave1> is that such a big deal?
[19:33] <darrelmiller> hdave1: What about putting the version number in the document and letting the parser deal with different versions?
[19:33] <hdave1> like "<mything version="1.0">
[19:33] <darrelmiller> yeah.
[19:34] <darrelmiller> I'm not saying it is a solution for every case, but for some scenarios it makes sense.
[19:34] <hdave1> i was hoping the parser would use the xml schema to help validate the doc....so by the time it's parsed its too late...
[19:34] <hdave1> sure
[19:34] <darrelmiller> The problem with xml schema is that it if the schema is precise enough to be useful, it is so damn brittle.
[19:34] <hdave1> i'm not saying i want to spend precious run-time with xml schema validation either...
[19:34] <hdave1> ain't that the truth
[19:35] <hdave1> here's a great example ---> attribute ID
[19:35] <hdave1> it should be required, yes?
[19:35] <hdave1> but of course it can't be or your clients will never be able to post a new xml model
[19:35] <hdave1> because it doesn't have an id
[19:35] <darrelmiller> depends :-)
[19:35] <hdave1> i hate that word
[19:36] <darrelmiller> I briefly tried using xml schema but don't any more.
[19:37] <hdave1> i did too....i was once a fan of contract first...by the time we were don't implementing, the contract was so diluted it was pointless
[19:37] <hdave1> s/don't/done
[19:37] <hdave1> know I am Java classes first and happy about it
[19:37] <hdave1> s/know/now
[19:37] <hdave1> i use the xml schema for management meetings :-)
[19:38] <darrelmiller> I write text based specs and a parser that reads and writes a compliant doc.
[19:38] <hdave1> that sounds cool
[19:38] <hdave1> I use WADL only for mgt meetings too....it seems pretty useless
[19:39] <darrelmiller> It's working well for me so far because my specs are relatively generic.
[19:39] <hdave1> do you use the compliant doc at runtime?
[19:39] <darrelmiller> I couldn't do it if I needed a spec for every business entity.
[19:39] <darrelmiller> Not sure what you mean?
[19:40] <darrelmiller> oh, duh. I didn't realize you we using my words hahaa.
[19:40] <darrelmiller> Yes, I use the "compliant doc" as the wire format.
[19:40] <hdave1> your own looser version of xml schema...
[19:41] <hdave1> out of curiosity, what do you think of JSON?
[19:41] <hdave1> ever use it?
[19:41] <darrelmiller> I have difficulty reading it.
[19:41] <darrelmiller> I've used it a bit.
[19:41] <hdave1> thats funny...i do too
[19:41] <talios> sounds like my discussion yesterday about using <link rel="glossary"/> to point to a "schema" for your business object
[19:42] <darrelmiller> talios: how so?
[19:42] <darrelmiller> You mean using xml schema?
[19:42] <talios> darrelmiller - in that the href might point to "http://someglossary-1.2"; or "…/someglossary-1.3"
[19:43] dkubb (~dkubb@50.92.131.237) left #rest ("Linkinus - http://linkinus.com";).
[19:43] <talios> the URI could identify a versioned glossary
[19:43] talios rereads the actual discussion :)
[19:44] <darrelmiller> My "spec" is just a human readable thing like http://stateless.co/hal_specification.html http://amundsen.com/media-types/collection/format/ or http://amundsen.com/hypermedia/profiles/
[19:45] <darrelmiller> The parser library encapsulates all the rules and exposes a DOM that is specific for that media type.
[19:45] <talios> Yeh - when I say glossary, I'm just talking something that identifies -somehow- the attributes of the payload.
[19:46] <talios> be that human readable or machine
[19:46] <darrelmiller> I have one media type for returning business entity data, one for sending updates, another for "layout" information, one for errors that I don't really use much and one other that I can't remember at the moment.
[19:46] <hdave1> i might call that a vocabulary
[19:47] <talios> yep. however "glossary" is only suitably matching IANA registered link relation :)
[19:47] <hdave1> why is the media type for sending updates different that the one that returns business entities?
[19:47] <hdave1> talios: are we really supposed to care about reusing IANA link relations that much?
[19:47] <darrelmiller> It allows me to do partial updates that are sequences and can update hierchial docs.
[19:48] <talios> hdave1 - maybe not, but if possible I'd prefer to as much as possible/
[19:48] <darrelmiller> hdave1: If you don't reuse an existing one you have to put a URI in the rel attribute. They're long ;-)
[19:48] <hdave1> darrelmiller: i would have thought the one media type could cover both cases...but I guess the hypermedia controls are
[19:48] <hdave1> different
[19:48] <hdave1> darrelmiller: really?
[19:49] <darrelmiller> If I retrieve a 30K document and edit one field, I don't want to send 30K back!
[19:49] <hdave1> darrelmiller: sure. where was I supposed to find out that I needed put a URI inside the rel attribute?
[19:49] <hdave1> this stuff is killing me...
[19:49] <darrelmiller> http://tools.ietf.org/html/rfc5988#section-4.2
[19:50] <hdave1> OMG (sighs)
[19:50] <darrelmiller> hdave1: Welcome to the world of the web where you are constantly discovering that someone did exactly what you are trying to do ten years ago.
[19:50] <hdave1> darrelmiller: why did I ever hope to get through this career without reading those RFCs.....
[19:51] <hdave1> lol
[19:51] <darrelmiller> Trust me. Once you get over the "dryness" they are the most fantastic resources.
[19:51] <darrelmiller> Many of them are full of genius.
[19:51] <hdave1> i have to agree with you...i've also become friends with a few JSR's recently and they are very readable too
[19:51] <darrelmiller> The genius of often not apparent until you have ignored their advice for a while.
[19:51] <hdave1> lol
[19:52] <hdave1> I just can't believe Al Gore found the time to write all these ;-)
[19:52] <darrelmiller> LOL
[19:52] <talios> +1 Would LOL again
[19:52] <darrelmiller> hdave1: This one is a foundation http://www.ietf.org/rfc/rfc3986.txt
[19:53] <darrelmiller> This one is cutting edge http://tools.ietf.org/html/draft-gregorio-uritemplate-04
[19:53] <hdave1> whats funny is usually I am comfortable walking in the footsteps of giants...but in the world of the internet, I can't find the footsteps!
[19:54] <darrelmiller> I'm really liking the possibilities of this one http://tools.ietf.org/html/draft-snell-http-prefer-10
[19:54] <hdave1> I like this URI template thing
[19:54] <darrelmiller> hdave1: It's a little over-engineered at the moment.
[19:55] <darrelmiller> This one is not an rfc but has so much potential http://www.opensearch.org/Specifications/OpenSearch/1.1
[19:55] <hdave1> maybe, but it seems to me that something could be done WRT my sending the same 10 zillion link relations to the client with every response
[19:56] <hdave1> if I could tell the client "hey...here are some URI templates...with some link relations and methods...I let you know when you can use them later"....it would be a lot more efficient
[19:56] <darrelmiller> Ahh, you mean by parameterizing... yeah. I use it for that sometimes.
[19:56] <hdave1> yes
[19:58] <hdave1> it is me, or should there be an HTTP header called "Content-Type-Version" ?
[19:58] <hdave1> that could be seperately a part of conneg?
[19:58] <hdave1> just seems cleaner...
[19:58] <darrelmiller> Content-Type: application/vnd.acme.todolist+xml;version=1
[19:59] <hdave1> i was looking today and it doesn't seem like Apache or Tomcat grok a version parameter on Content-Type
[19:59] <darrelmiller> or just Content-Type: application/vnd.acme.todolist.v1+xml
[20:00] <darrelmiller> intermediaries are supposed to treat it pretty much as a single opaque string. I think.
[20:00] <hdave1> yup
[20:00] <darrelmiller> Apparently some proxies drop the params, which is why it's prefered to just put it part of the subtype.
[20:00] <hdave1> oh ... didn't know that...
[20:00] <darrelmiller> Or just put it inside the doc and make your parser smart.
[20:01] <darrelmiller> they are not supposed to, but hey, it's a big bad world out there.
[20:01] <hdave1> lol
[20:02] <hdave1> when you are minting new media types, do you put "v1" in it initial or just leave off any version identifier?
[20:02] <hdave1> meaning do nothing until v2 comes along
[20:03] <darrelmiller> I leave it off. I consider have to put a version number is an admission of defeat.
[20:03] <hdave1> i live in a non-stop world of defeat
[20:03] <darrelmiller> It means I didn't think hard enough when designing the initial media type.
[20:04] <hdave1> it means the world isn't dead-set on kicking your butt enough of the time
[20:04] <darrelmiller> I'm partially kidding but remember, the media type is your point of coupling. You really don't want this bit to change.
[20:04] <hdave1> i agree...its worth the effort to work hard to make sure they don't change....
[20:05] <darrelmiller> So, putting the extra effort into designing it to be flexible to accommodate future requirements is well worth while.
[20:05] <hdave1> yes, but if the XML structure of your payload has to be changed in an incompatible way, then as I see it, the media type needs to be versioned...no way around it
[20:06] <hdave1> well unless you do URL versioning (yikes)
[20:06] <darrelmiller> Let's not talk about url versioning.
[20:06] <darrelmiller> That is admitting your entire api is a complete failure :-)
[20:07] <hdave1> i hope the day never comes when i have to consider that as an option
[20:07] <talios> hdave1: are you not just versioning the -representation- not the resource location
[20:07] <hdave1> talios: I am 90% concerned with versioning the representation, not so much with the resource location
[20:08] <hdave1> talios: plus (please correct me if i am wrong) if I follow HATEOAS right, then 90% of my URL's are server generated anyway, yes?
[20:08] <talios> technically 100% of your urls are :)
[20:08] <hdave1> talios: I am hoping I can muck around with URLs and not even touch the clients!
[20:08] <hdave1> talios: there still has to be a entry point
[20:08] <hdave1> so maybe 99.9% of the URLs
[20:09] <talios> but yes, if your clients follow linking then yes
[20:09] <darrelmiller> Clients can construct urls. They just have to do it based on rules defined in the media type spec.
[20:10] <hdave1> darrelmiller: yes, but I am hoping to make it easy on them
[20:10] <darrelmiller> yeah, I agree, it's best to avoid it if you can.
[20:10] <hdave1> ok...so here is my confession...
[20:11] darrelmiller starts the video recording.
[20:11] <hdave1> I have always done RPC based stuff in the past...(SOAP, AMF, CORBA, etc.)
[20:11] <hdave1> i fell into REST because I was using CXF for SOAP, and found out I could configure it to use Jackson to produce JSON and
[20:11] <hdave1> that Jackson would reuse most of my JAX-B annotations
[20:12] <darrelmiller> hdave1: You should watch this http://www.infoq.com/presentations/vinoski-rpc-convenient-but-flawed You would enjoy it.
[20:12] <hdave1> so I decorated my service class with JAX-RS
[20:12] talios cringes at JAX-RS
[20:12] <hdave1> and voila! I had an HTTP-RPC web services that I thought I could call rest
[20:12] <hdave1> then I read about HATEOAS....and blew a fuse
[20:12] <hdave1> depression
[20:12] <hdave1> anxiety
[20:12] <hdave1> sleeplessness
[20:13] <hdave1> and then I realized that RPC sucks
[20:13] <darrelmiller> I think many of us followed a similar path.
[20:13] <hdave1> and now I can't go back
[20:13] <darrelmiller> I just did it on the Microsoft platform.
[20:13] <hdave1> but I am so new to REST...
[20:13] <hdave1> so I am a man without a home
[20:13] <hdave1> </confession>
[20:13] <darrelmiller> Do you live anywhere near Greenville, SC ?
[20:14] <hdave1> Boston
[20:14] <talios> so far away
[20:14] <darrelmiller> Hmm, I'm not far. Just across the border in Montreal.
[20:14] <hdave1> you have no idea....
[20:14] <talios> hdave1 - I'm in New Zealand. I have an idea :)
[20:14] <darrelmiller> haha.
[20:14] <hdave1> I love New Zealand...
[20:14] <hdave1> take good care of it talios
[20:15] <hdave1> it where my and half of America is headed after the US goes down the tubes!
[20:15] <darrelmiller> We have an annual event in Greenville called RESTfest. It's a great place to learn.
[20:15] talios love to attend RESTfest
[20:15] <hdave1> darrelmiller: when is the next one?
[20:15] <darrelmiller> Probably august or sept.
[20:15] <hdave1> i will try to be there
[20:15] <darrelmiller> mamund and bigbluehat organize it.
[20:16] <hdave1> though august in SC is sweltering
[20:16] <darrelmiller> It has been a huge help for me. I've learned so much there .
[20:16] <hdave1> are there recording, docs from the last one?
[20:17] <darrelmiller> Well as a matter of fact there are.
[20:17] <talios> there were some videos I saw
[20:17] <hdave1> *** searching
[20:17] <darrelmiller> The first year were pretty crappy because I was doing it on a web cam and a laptop.
[20:17] <darrelmiller> They are on vimeo. Hold on.
[20:17] <darrelmiller> http://vimeo.com/channels/restfest
[20:18] <hdave1> don't type "restfest" in google and hit "I'm feeling lucky"....just plain weird!
[20:18] <darrelmiller> This years were much better because we had pro's do it. Although they missed some sessions which I streamed off my iPad.
[20:18] <hdave1> nice...well I know what I am doing tomorrow then...
[20:19] <hdave1> so we use an agile development approach here ...small team
[20:19] <hdave1> i think I am going to start with two media types for each of the two major components of our system
[20:19] <hdave1> and try hard to stick with them unless somebody can formulate a really compelling reason we why need another one
[20:20] <darrelmiller> have you found the videos page in the implementing rest wiki yet?
[20:20] <hdave1> yes
[20:20] <hdave1> wait
[20:20] <hdave1> no
[20:20] <darrelmiller> There are some great videos there.
[20:20] <darrelmiller> http://code.google.com/p/implementing-rest/wiki/Video
[20:20] <hdave1> wow...was all over that wiki and totally missed those
[20:21] <hdave1> they need to be highlighted on the landing page I think...
[20:21] <hdave1> oh wait -- they are
[20:21] <hdave1> lol
[20:21] <hdave1> talios: why don't you like JAX-RS?
[20:21] <darrelmiller> Oh, yeah. The first one that says ****NEW **** :-)
[20:24] <hdave1> ok...night all..
[20:24] <darrelmiller> night.
[20:46] talios (~textual@akl.smx.co.nz) left irc: Quit: Textual IRC Client: http://www.textualapp.com/
[21:41] dreinull (~dreinull@ip-78-94-220-161.unitymediagroup.de) joined #rest.
[21:47] kennethreitz (~kennethre@207.239.114.206) joined #rest.
[22:30] Wombert (~Wombert@xdsl-78-35-206-172.netcologne.de) joined #rest.
[22:42] kennethreitz (~kennethre@207.239.114.206) left irc: Read error: No route to host
[22:44] Blazeix (~Blazeix@71.74.190.197) left irc: Ping timeout: 260 seconds
[23:00] Wombert (~Wombert@xdsl-78-35-206-172.netcologne.de) left irc: Quit: Wombert
[23:20] quest88 (~quest88@c-98-207-205-137.hsd1.ca.comcast.net) left irc: Quit: quest88
[00:00] --- Fri Jan 13 2012