[02:20:54] ivanfi (~ivanfi@62.159.77.164) joined #rest. [02:31:01] blongden (~blongden@nocarrier.co.uk) joined #rest. [03:04:36] Wombert (~Wombert@dslb-088-065-199-130.pools.arcor-ip.net) left irc: Quit: Wombert [03:44:36] Wombert (~Wombert@dslb-088-065-199-130.pools.arcor-ip.net) joined #rest. [03:51:11] Hakon|mbp (~hakon1@84.202.136.151) joined #rest. [04:14:05] Hakon|mbp (~hakon1@84.202.136.151) left irc: Remote host closed the connection [04:48:16] mr_yall (~mryall@host86-128-59-168.range86-128.btcentralplus.com) left irc: Ping timeout: 240 seconds [04:48:19] blongden (~blongden@nocarrier.co.uk) left #rest. [05:24:18] mikekelly (mikek@s3x0r.biz) left irc: Quit: Lost terminal [05:25:30] mikekelly (mikek@s3x0r.biz) joined #rest. [05:26:20] yo! [05:26:52] hei! [05:28:08] mamund: I think your questions to Erik were pretty fair, conversation sort of died [05:28:42] technoweenie: so I'm looking at avoiding instance_eval in this templating dsl [05:29:13] but it just ends up reading horrible [05:29:19] https://gist.github.com/9abeb5ad16424566dae1 [05:47:28] vmil86 (~vmil86@78.57.245.80) joined #rest. [06:05:54] grove (~grove@aggw006.cappelendamm.no) left irc: Quit: grove [06:33:03] oi [06:33:18] oi oi [06:35:04] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Ping timeout: 240 seconds [06:37:55] hoelzro (~hoelzro@208.70.82.85) joined #rest. [06:39:23] mikekelly: yea its a matter of implicit vs explicit [06:39:47] technoweenie: right - if I use instance_eval the problem is it makes it impossible to use your own object with, right ? [06:40:03] yea, it modifies self and does unexpected things [06:40:16] yeah I get it - it's just that is looks like ass if you do it any other way [06:40:27] heh, ok [06:40:29] do what you like [06:40:33] people love rspec [06:40:47] I thought all the cool kids like MiniTest now ? [06:41:14] maybe [06:41:27] :) [06:42:23] technoweenie: do you think a templating langauge needs to give that kind of access to the scope ? [06:42:49] I'm htinking it doesn't but I'm not sure if I'm just trying to conivnce myself instance_eval is 'ok' [06:43:17] just make sure you have good docs i guess [06:43:31] i've dealt with enough weird ass bugs in apis like that to never use them again [06:43:48] did you look at the gist ? [06:44:19] yea [06:44:20] maybe I'm being OCD but it's not very readable to me :( [06:44:22] fu-manchu (~fumanchu@adsl-99-30-180-185.dsl.sfldmi.sbcglobal.net) joined #rest. [06:44:29] i probably wouldnt use either tbh [06:44:40] oh. [06:44:55] they look the same to me [06:45:04] some are longer because they specify the object in front? [06:45:11] but you also use a long ass variable name [06:45:53] dunno what else to use [06:46:01] I can use objects for the obejcts_resource [06:46:07] but I can't use object on the object_resource [06:46:17] cos it conflicts.. [06:46:42] sounds like a pickle [06:46:48] lol [06:47:04] maybe I shoud just create a new programming langauge [06:47:12] or try Python [06:47:14] bradley-holt (~bradley-h@65-183-135-35-dhcp.burlingtontelecom.net) joined #rest. [06:48:30] python would have be more explicit [06:48:36] wer [06:48:42] python would have you be more explicit [06:48:49] yeah I was just pretending to be a fickle turd [06:48:55] I'm not, really [06:49:01] hey follow your heart man [06:49:11] lol [06:49:13] dont let the feedback of one irc ass make you doubt yourself [06:49:32] it's DHH too right ? [06:49:41] he's like Ruby Jesus or whatver [06:49:42] what is? [06:50:10] the anti-instance_eval thing came from him too [06:50:16] is that right ? [06:50:34] bigbluehat (~bigblueha@adsl-98-84-70-208.gsp.bellsouth.net) joined #rest. [06:50:41] yea we share the same opinion on that [06:50:59] heil Ruby Jesus [06:51:49] ok thanks [06:52:00] I guess i'll do the sensible thing and avoid instance_eval [06:52:51] I guess I could just pass |hal| into the block [06:53:20] yeah that's a good plan, I'll do that [06:53:59] naming things.. [06:54:16] the only thing left to crack for me, since I've already covered cache invalidation [06:54:22] call it hal9000 [06:54:33] I thought it was two things? [06:54:44] naming things, cache invalidation and off by one errors [06:54:44] :) [06:55:03] OH SNAP [06:55:19] mikekelly: anyways all i'm saying is its my opinion, and a lot of other rubyists use rspec and similar libraries [06:55:33] so they may be more used to instance_eval [06:55:58] technoweenie: yeah I'd rather cause as little friction as possible [06:56:31] I think I basically agree with avoiding it, I just don't like the ugliness [06:56:37] http://www.youtube.com/watch?v=Du_RTMmofWM [06:57:20] grove (~grove@193.201.9.46.customer.cdi.no) joined #rest. [06:57:36] bwahaha [06:57:40] I fucking love this guy [06:57:48] everything he does is awesome [07:08:34] hello fellow REST enthusiasts! I'm implementing a REST API, and I was wondering if it would be reasonable to return 304 Not Modified if a client PUTs a resource, but the contents of the PUT do not differ from the current representation on the server. Thoughts? [07:10:29] Action: mikekelly shrugs [07:10:31] no, that'd be in violation of the HTTP specification [07:11:02] "If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields." [07:11:07] it's for conditional requests only [07:11:45] Wombert: I kind of intrepreted that as a sufficient, but not neccessary condition for 304 [07:12:10] if I shouldn't use 304, is there a way I should indicate to the client that "hey, the content you uploaded was already here"? [07:12:54] you could send a 409 Conflict if you want [07:13:13] or a 200 OK with a response body containing that information [07:13:43] if the contents of the PUT do not differ I'd say you finally reached the holy grail of idempotence which you wanted anyway, and 200 OK is the correct response [07:14:43] fu-manchu: good point; I didn't consider that [07:24:14] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest. [07:37:28] Action: mamund shows up [07:39:54] whoo-hoo! final proof on my "Hypermedia" book goes 'to the printer' today! [07:39:59] Action: mamund does a happy dance [07:43:34] congrats [07:49:53] Action: Wombert high-fives mamund [07:50:00] oh, now that you're all here [07:50:07] someone asked me an interesting question the other day [07:50:16] how to do a CAPTCHA in a RESTful interface [07:50:51] I'm thinking: let the client hit the "image" URI, redirect him to a temporary URL with a CAPTCHA document (specced in the media type) [07:51:12] that contains a form that submits somewhere, which in turn redirects to the real image URI with some kind of key in the query string or so [07:51:31] that guy is already using HTTP auth for the service, so that won't work :) [07:51:35] anyone got a better idea? [08:02:52] DracoBlue (~Adium@dslb-088-075-066-254.pools.arcor-ip.net) joined #rest. [08:02:57] DracoBlue (~Adium@dslb-088-075-066-254.pools.arcor-ip.net) left #rest. [08:10:17] DracoBlue (~Adium@dslb-088-075-066-254.pools.arcor-ip.net) joined #rest. [08:10:26] DracoBlue (~Adium@dslb-088-075-066-254.pools.arcor-ip.net) left irc: Client Quit [08:12:45] Wombert: umm... [08:12:52] not too many takers on that thing, eh? [08:13:11] honestly, i think you might be trying to push a rope up a hill [08:15:20] :p [08:15:23] mamund: oh btw [08:15:36] mamund: HATEOAS is in itself a brilliant way to get around the read-after-write problem [08:16:25] a server could return Location: http://j12893zhiu12ejk.someservice.com/products/1234 after it's being created, to make sure subsequent reads always hit the correct shard, or at least a part of the system where the write is guaranteed to have been replicated to [08:17:13] and then every few hours or days, those "dynamic" hostnames could simply be "re-wired" to point to a load balancer again in order to make sure that there are no "hot-spots" on any domain [08:18:40] did I explain that well? :p [08:20:53] o/ all [08:28:07] whartung: yo! [08:47:18] ivanfi (~ivanfi@62.159.77.164) left #rest. [09:10:15] KevBurnsJr (~kevburnsj@c-76-126-10-63.hsd1.ca.comcast.net) left irc: [09:22:31] Wombert: that's a very good point [09:22:34] blog it! [09:22:48] trygvis: I guess I need to start blogging then :D [09:22:58] technoweenie (~technowee@host-86-220-9-69.midco.net) left irc: Remote host closed the connection [09:23:12] or, rather, I need to start blogging things other than funny cat videos :p [09:24:15] this might actually be doable with Varnish in an easy-ish way [09:24:28] obviously the idea is that you still don't hit the backend server directly [09:24:47] the hostname part is just supposed to help the load balancer determine where to hand the request [09:25:02] maybe it can be done completely dynamically and with a wildcard DNS entry [09:26:22] hoelzro (~hoelzro@208.70.82.85) left #rest. [09:27:24] basically you could pick a shared secret that is used to hash server names with a date or so, and all the load balancer would do is "brute-force" them for the current day [09:27:29] that only works for few servers though [09:38:17] KevBurnsJr (~KevBurnsJ@50.0.103.39) joined #rest. [09:40:38] what are y'all babbling about? [09:45:50] lol. [09:45:51] rude. [09:54:26] Wombert (~Wombert@dslb-088-065-199-130.pools.arcor-ip.net) left irc: Quit: Wombert [10:00:49] apok (~apok@c-107-3-149-167.hsd1.ca.comcast.net) joined #rest. [10:12:18] bigbluehat (~bigblueha@adsl-98-84-70-208.gsp.bellsouth.net) left irc: Quit: Leaving. [10:54:07] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Quit: Leaving... [10:55:23] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest. [11:23:01] alexsdutton (~alex@comma.splice.org.uk) left irc: Ping timeout: 240 seconds [11:24:13] alexsdutton (~alex@comma.splice.org.uk) joined #rest. [11:34:33] alexsdutton (~alex@comma.splice.org.uk) left irc: Remote host closed the connection [11:34:48] alexsdutton (~alex@comma.splice.org.uk) joined #rest. [11:36:41] grove (~grove@193.201.9.46.customer.cdi.no) left irc: Quit: grove [11:36:47] bigbluehat (~bigblueha@adsl-98-84-70-208.gsp.bellsouth.net) joined #rest. [12:36:02] talios (~amrk@akl.smx.co.nz) joined #rest. [12:44:27] bradley-holt_ (~bradley-h@65-183-135-35-dhcp.burlingtontelecom.net) joined #rest. [12:47:11] bradley-holt (~bradley-h@65-183-135-35-dhcp.burlingtontelecom.net) left irc: Ping timeout: 248 seconds [12:47:12] Nick change: bradley-holt_ -> bradley-holt [12:51:37] apok (~apok@c-107-3-149-167.hsd1.ca.comcast.net) left irc: Remote host closed the connection [12:51:51] apok (~apok@c-107-3-149-167.hsd1.ca.comcast.net) joined #rest. [13:12:00] bradley-holt (~bradley-h@65-183-135-35-dhcp.burlingtontelecom.net) left irc: Quit: bradley-holt [13:58:32] grove (~grove@193.201.9.46.customer.cdi.no) joined #rest. [14:12:54] Wombert (~Wombert@dslb-088-065-199-130.pools.arcor-ip.net) joined #rest. [14:20:44] bigbluehat (~bigblueha@adsl-98-84-70-208.gsp.bellsouth.net) left irc: Quit: Leaving. [14:20:52] grove (~grove@193.201.9.46.customer.cdi.no) left irc: Quit: grove [14:32:52] Wombert (~Wombert@dslb-088-065-199-130.pools.arcor-ip.net) left irc: Quit: Wombert [14:39:39] vmil86 (~vmil86@78.57.245.80) left irc: Remote host closed the connection [14:58:11] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Quit: Leaving... [15:19:42] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest. [15:28:20] Action: mamund is gone now [15:32:51] SvenDowideit (~SvenDowid@203-206-171-38.perm.iinet.net.au) joined #rest. [15:42:26] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) joined #rest. [16:23:09] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Read error: Connection reset by peer [16:56:22] gchristensen (~gchristen@unaffiliated/grahamc) joined #rest. [17:45:09] sgronblo (~sgronblo@tuxedo.abo.fi) joined #rest. [17:45:33] Is being resource based an essential part of rest or is it just a recommendation? [17:57:35] KevBurnsJr (~KevBurnsJ@50.0.103.39) left irc: [18:05:08] as opposed to? [18:07:33] well URL/URI is "resource" so... [18:11:25] as opposed to service-oriented urls where the action is in the url [18:11:40] esesntial [18:13:57] I was just reading the page about google translate's "rest interface" and thought it sounded a bit funny [18:14:15] "REST, or Representational State Transfer, in the Google Translate API is somewhat different from traditional REST. Instead of providing access to resources, the API provides access to a service. As a result, the API provides a single URI that acts as the service endpoint." [18:14:41] Wsan't this exactly what you are trying to get away from by being restful [18:15:05] Although "restful" seems to include so many different aspects and feels quite vague so it's hard to tell [18:15:06] !facepalm [18:15:18] :) [18:16:18] I'm sure it should be possible to make fun of that statement quite easily [18:17:37] "An automobile, in the google world is slightly different from traditional automobiles. Instead of using an engine to power the automobile, it is being pulled by a horse. As a result you can whip the horse to go faster." [18:18:28] I'm sure it's possible to do better though [18:18:30] sgronblo: actually - this raises a question on action url's, or state changes. we've just started using ;'s to signify an action against a resource, such as /customer/32 and /customer/32;cancel - feels wrong, spec says ; is reserved to specialise the segment, which feels ok in my mind, but still. [18:18:52] Who are "we"? [18:19:13] we = smxemail.com - my work. [18:19:33] shouldnt that just be put cancelled=true to /customer/32 ? [18:19:43] sgronblo: yes [18:19:50] well PATCH [18:19:52] ;) [18:20:16] oh is patch if you dont wanna send the whole representation? [18:20:20] yes [18:20:25] sweet [18:20:33] I was just about to bring that up when you said yes [18:20:38] also not idempotent [18:20:49] I've been wondering about that for a long time [18:20:54] sgronblo: probaby PATCH , but then - theres multiple side effects being incurred. theres no "cancelled" field on the resource. Having something that can be easily separated at the server side level ( i.e. class/mounts ) is handy [18:21:19] rather than the server going "oh, you posted cancell, so I should do XXX, but you also posted foobar, so I should also do YYY" [18:22:40] but doesnt that mean that there should be a cancelled field? [18:23:17] originally I thought I should be posted specific media types, i.e. application/vnd+cancellationrequest - which would work really work, but that leads to media type explosions [18:23:44] s/posted/posting/ [18:25:53] Action: talios has a few ideas that could work well using HAL, which will be handy once we move over to that. [18:26:45] hardware abstraction layer? [18:27:00] Hypertext Application Language - http://stateless.co/hal_specification.html [18:27:31] so when is patch gonna be mainstream (ie used in rails :) ? [18:27:58] is that guaranteed to be passable thru firewalls and proxies as well [18:29:50] steveklabnik: where does it say that thou shalt not useth a single service endpoint though? [18:33:27] sgronblo: im on the phone, one second. [18:35:23] dont worry, i'm not going anywhere soon [18:35:30] expect lunch in 1,5h :) [18:42:39] already getting hungry though [18:43:59] kay [18:44:01] so [18:44:48] http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm#sec_5_2_1_1 [18:44:55] The key abstraction of information in REST is a resource. [18:45:00] doesnt get more authorative than that [18:45:15] for more about this idea, http://martinfowler.com/articles/richardsonMaturityModel.html [18:45:27] now, REST apis should actually have a single endpoint [18:45:28] actually [18:45:39] but through hypertext, drive the state of the application from there. [18:46:02] actions in URIs aren't good, http verbs are actions, URIs are nouns [18:47:25] well ok that is good enough, thanks [18:48:44] :) [18:49:27] enough material to try to a smartass on twitter about it [18:51:00] hahaha [18:53:05] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) left irc: Ping timeout: 260 seconds [18:53:52] its so funny when everybody wants to get in on this hot RESTful action without really knowing what it's all about [18:54:07] apok (~apok@c-107-3-149-167.hsd1.ca.comcast.net) left irc: Ping timeout: 244 seconds [18:54:19] you don't need to tell us. ;) [18:54:19] I don't claim to be an expert myself but I am at least aware of my ignorance. [18:54:52] OMG OUR API IS RESTFUL IT HAS COOL LOOKING URLS!!!!!11 [20:00:02] KevBurnsJr (~kevburnsj@c-76-126-10-63.hsd1.ca.comcast.net) joined #rest. [20:52:46] talios (~amrk@akl.smx.co.nz) left irc: Quit: Bye! [21:48:12] KevBurnsJr (~kevburnsj@c-76-126-10-63.hsd1.ca.comcast.net) left irc: [22:47:37] gchristensen (~gchristen@unaffiliated/grahamc) left irc: Quit: Leaving... [00:00:00] --- Tue Nov 22 2011