#rest on irc.freenode.net 2010-07-06 (txt)

[00:09] peta (~peta@91-66-178-54-dynip.superkabel.de) left irc: Quit: peta
[00:35] nkoza (~NKoza@201.216.248.178) left irc: Quit: Client exiting
[01:10] bigbluehat (~byoung@adsl-71-143-157.gsp.bellsouth.net) left irc: Quit: bigbluehat
[02:28] sbanwart (~sbanwart@99-177-126-136.lightspeed.bcvloh.sbcglobal.net) left irc: Remote host closed the connection
[04:47] Joeconyers (~Joe@ool-182fafef.dyn.optonline.net) left irc: Ping timeout: 252 seconds
[04:51] mahiti_skt (~mahiti@122.166.127.74) joined #rest.
[05:04] mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) joined #rest.
[05:38] algermissen (~algermiss@p5490590C.dip.t-dialin.net) joined #rest.
[06:04] algermissen (~algermiss@p5490590C.dip.t-dialin.net) left irc: Ping timeout: 240 seconds
[06:45] KevBurnsJr (KevBurnsJr@c-69-181-187-21.hsd1.ca.comcast.net) left irc: Ping timeout: 245 seconds
[07:03] KevBurnsJr (KevBurnsJr@c-69-181-187-21.hsd1.ca.comcast.net) joined #rest.
[07:16] graste (~graste@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) joined #rest.
[07:50] mahiti_skt (~mahiti@122.166.127.74) left irc: Ping timeout: 260 seconds
[07:52] mahiti_skt (~mahiti@122.166.127.74) joined #rest.
[08:21] Gracenotes (~person@wikipedia/Gracenotes) left irc: Ping timeout: 264 seconds
[08:23] crohr (~crohr@parachute.irisa.fr) joined #rest.
[09:15] RestBot joined #rest.
[09:57] Gracenotes (~person@wikipedia/Gracenotes) joined #rest.
[09:57] mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) left irc: Quit: brb
[10:53] Joeconyers (~Joe@ool-182fafef.dyn.optonline.net) joined #rest.
[11:22] twilliams_ (41decaca@apache/committer/twilliams) joined #rest.
[11:28] Joeconyers (~Joe@ool-182fafef.dyn.optonline.net) left irc: Ping timeout: 240 seconds
[12:29] bigbluehat (~byoung@adsl-71-143-157.gsp.bellsouth.net) joined #rest.
[12:35] twilliams_ (41decaca@apache/committer/twilliams) left irc: Ping timeout: 252 seconds
[12:59] Joeconyers (~Joe@ool-182fafef.dyn.optonline.net) joined #rest.
[12:59] mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) joined #rest.
[13:11] twilliams_ (41decaca@apache/committer/twilliams) joined #rest.
[13:49] mahiti_skt (~mahiti@122.166.127.74) left irc: Quit: Ex-Chat
[13:51] cybernd (~Miranda@193.178.208.8) joined #rest.
[13:59] <cybernd> q: what is the prefered practice to define optional parameters? example my/resource/productId/5/optionalAdditionalId/7 (the call should also work if the second parameter is not available)
[14:04] twilliams_ (41decaca@apache/committer/twilliams) left irc: Ping timeout: 252 seconds
[14:06] <cybernd> im sure that im able to get the parameter working by using the regexp path param binding mechanism, but i know that im bending something in an unintentional way if i do so
[14:11] twilliams_ (41decaca@apache/committer/twilliams) joined #rest.
[14:26] mamund is up and running
[14:29] bradley-holt_ (~bradley-h@65-183-135-35-dhcp.burlingtontelecom.net) joined #rest.
[14:30] bradley-holt_ (~bradley-h@65-183-135-35-dhcp.burlingtontelecom.net) left irc: Client Quit
[14:31] bradley-holt (~bradley-h@65-183-135-35-dhcp.burlingtontelecom.net) joined #rest.
[14:42] <mamund> cybernd: if i understand your Q, you can set whatever rules you want on how the server interprets the URI
[14:42] <mamund> is this about how to communicate to clients that some parts are optional or ...
[14:42] <cybernd> basically i can implement serverside whatever i want, but in this case its not supported out of the box using the rest api
[14:42] <mamund> is it about implementation details on the server-side?
[14:43] <mamund> so this is a server-side coding issue RE the tools you're working with
[14:43] <cybernd> nope more like is it okay to have an resource endpoint like a/1/b/2 when i expect that a/1 should also work with the same resource end point
[14:44] <mamund> the "rest api" of what toolset?
[14:44] <cybernd> if i reflect twitters api i would end up like a/1?b=2 (while b is optional but a mandatory)
[14:45] Joeconyers (~Joe@ool-182fafef.dyn.optonline.net) left irc: Ping timeout: 260 seconds
[14:45] <cybernd> the rest api of my own toolset im developing :)
[14:45] Joeconyers (~Joe@ool-182fafef.dyn.optonline.net) joined #rest.
[14:46] <mamund> ok
[14:46] <cybernd> but there exists JAX-RS which is the standard way in java to deal with rest and this api does not support something like /a/1[/b/2] - okay it supports it but basically if i bend the api and implement it like /a/{param} while param will contain a and b together
[14:46] <mamund> ahhh
[14:46] <mamund> well, that's a JAX-RS issue.
[14:46] <cybernd> the question is: is it a jax-rs limitation or something which should be avoided
[14:47] <mamund> FWIW, my own toolset uses regex in a manner you allude to
[14:47] <cybernd> because some dotnet tools have the same limitations
[14:47] <mamund> this is about tools, not HTTP or RESTE
[14:47] <cybernd> nope about rest
[14:47] <cybernd> the basic question is: should /a/1 be treated as different resource as /a/1/b/2
[14:47] <mamund> sure, it's a diff "resource"
[14:48] <cybernd> is this one resource with one optional parameter, or are these 2 different resources
[14:48] <mamund> but is that really the Q?
[14:48] <mamund> diff resources.
[14:48] <mamund> why is this an important question for you?
[14:48] <mamund> (sorry, i came in late maybe)
[14:48] <cybernd> if this is the case, jax-rs supports it, because its not meant to process 2 different resources with the same java method
[14:49] <cybernd> was just not sure if this shall be treated as optional parameter or not
[14:49] <mamund> i understand.
[14:49] <cybernd> its an important question to understand the true meaning of "resource" in rests context
[14:49] <darrelmiller_> I think the server side implmentation issue is, should this be handled by one or two controllers.
[14:50] <cybernd> not onle this - think about documentation
[14:50] <darrelmiller_> When server side frameworks start to introduce their notion of a "resource" you start to run into issues.
[14:50] <cybernd> this implies also that there need to be 2 ressources documented instead of one with one optional portion of the parameter
[14:51] <darrelmiller_> For example, /foo and /foo?q=1 are two different resources, but many frameworks would handle these with the same "resource controller"
[14:51] <cybernd> this means that the url parameters behind ? are also treated as significant for resource distinction?
[14:51] <darrelmiller_> Yes
[14:52] <cybernd> damn :D i hoped that the resource ends on the left side of the ?
[14:52] <darrelmiller_> :-) I know, in some we ways I think we all wished it worked like that. But it doesn't.
[14:52] <cybernd> my main issue is simply developer vs spec :)
[14:53] <darrelmiller_> Url's should be opaque to the client and intermediaries so it really does not matter how the URI is different, if it is different, it is a different resource.
[14:53] <cybernd> the dev knows that its easy to bend every rule easily - because the whole thing is just one string which can be parsed in all ways
[14:54] <darrelmiller_> Client dev or server dev? Server dev is free to parse away.
[14:54] <cybernd> somehow related question in this context - given is a uri spec "/a/1" while there are only nubers allowed as last parameter
[14:55] <cybernd> is it expected to have a 400 or a 404 if someone tries to call /a/myBad1
[14:55] <darrelmiller_> I would say 404, personally.
[14:56] <cybernd> jax-rs default is 404 in this case
[14:56] <cybernd> my personal feeling was: thats odd i want to throw my own custom error in case of a malformed parameter
[14:57] <cybernd> as always: thx for your feedback
[14:57] <darrelmiller_> The problem is how could the client have known it was supposed to be an int?
[14:58] <cybernd> exactly
[14:58] <darrelmiller_> To my knowledge there are very few specs that provide client side uri construction rules, and I have not seen any that have type information defined.
[14:59] <cybernd> my thought was something like - if i avoid using auto parsing to the number datatype, i can throw a custom error like 400 "parameter needs to be datatype x" in case of the notfound
[15:00] <cybernd> which would most probably be more valuable as feedback for the client dev
[15:02] <darrelmiller_> There is nothing to stop you returning descriptive information in the entity body when you return the 404.
[15:03] <cybernd> yeah there is just one minor issue - i need to bend the jax-rs framework again, because if jaxrs throws a 404 because it was not possible to find a matching resource, i have no life cycle entry point to add custom parameter interpretation code
[15:04] <cybernd> in other words: i need to accept the request in order to throw a 404 after i found the resource
[15:04] <darrelmiller_> Do you mean you can't easily return custom content in the body?
[15:04] <darrelmiller_> I understand.
[15:05] <cybernd> but thats only a minor "definition" problem - easy to bypass in code - it just feels odd again
[15:07] <darrelmiller_> It is a classic framework issue. When the framework tries to do too much magic for you it hurts you in the edge cases.
[15:07] <mamund> really a bummer when toolsets get in the way
[15:07] <darrelmiller_> *cough* WCF *cough*
[15:08] <mamund> i run into many cases where devs are "lead" down the path of "least resistance" for the toolset...
[15:08] <mamund> and that results in terrible implementations
[15:08] <mamund> WCF, ASP.NET MVC, the list goes on.
[15:08] <mamund> even more annoying is when folks _try_ to built RESTful implementations..
[15:09] <darrelmiller_> mamund: You mean like all these frameworks that automagically support generic XML and JSON but no other media-type!
[15:09] <mamund> and run into blockers like cybernd is describing...
[15:09] <mamund> sometimes the result is devs decide REST is a bad idea!
[15:09] <mamund> darrelmiller: just one of the many annoyances
[15:09] <mamund> i find URI Handling and Routing one of the most annoying -
[15:09] <mamund> just as cybernd describes
[15:10] <mamund> it makes simple implementations so frustrating
[15:10] <mamund> toolsets should not be messing w/ cybernd's optional args!
[15:10] <darrelmiller_> Or my other favourite pet peeve. Using the same controller to handle both lists of entities and the single entities.
[15:11] <cybernd> hmm im not sure mamund
[15:11] <cybernd> in this case its a java jsr and often the jsr's are rock solid because they allow only really interoperable stuff
[15:11] <darrelmiller_> mamund: I thought you were happy with the regex style routing? What part of framework routing bugs you?
[15:11] <cybernd> this means, when i run into an edge case it might be an indication that this edge case syntax is something which will make the live of other client devs really really hard
[15:11] crohr (~crohr@parachute.irisa.fr) left irc: Quit: crohr
[15:12] <cybernd> so for example - its easy for me to bend every rule, no problem - just some custom code, but it might be possible that in future when someone tries to implement a ruby client it might be harder for him
[15:12] <cybernd> (i got no clue about ruby support - just an example - just a language i did not thought about)
[15:13] <cybernd> basically im trying to say that it might be better to align on the intersection which is easy to use in all toolsets
[15:14] <darrelmiller_> cybermd: If the server framework constrains you it will be just as much of a pain to all client devs. It is unlikely to cause a language specific issue.
[15:15] <cybernd> im not sure if it constraints me - because it might also mean: what you are doing is horrible wrong, move this optional parameter to the xml request payload which is already used in your call
[15:15] <darrelmiller_> I regularly use optional parameters in URIs.
[15:16] <cybernd> using /a/1 or ?a=1
[15:16] <darrelmiller_> e.g. /Customer/3/ContactInfo /Customer/layout
[15:16] <darrelmiller_> Both...
[15:17] <cybernd> thx
[15:17] <darrelmiller_> or /Customer/3?viewOnly=true
[15:18] <cybernd> i think i will try to treat them as "overloaded" resources instead of trying to bend the path binding mechanism to handle optional stuff within the same path
[15:35] Joeconyers (~Joe@ool-182fafef.dyn.optonline.net) left irc: Ping timeout: 276 seconds
[15:52] Joeconyers (~Joe@ool-182fafef.dyn.optonline.net) joined #rest.
[16:07] graste (graste@ip-vlan-obckunde-02-217-66-60-14.pixelpark.net) left #rest.
[16:24] <cybernd> darrelmiller_ : i tried to find something about query parameters and it seems like there are many examples where people are convinced that only the left side of the ? is significant for the "resource".
[16:49] <mamund> cybernd: /location;39.1.0,84.36.2
[16:49] <mamund> what's the resource?
[16:51] <cybernd> i think the full thing "/location;39.1.0,84.36.2"
[16:52] <mamund> why?
[16:52] <cybernd> because ; has no special meaning
[16:52] <cybernd> you might tread it special in your ap as parameter seperation, but basically it has no special meaning for the url definition
[16:52] <mamund> well, it does actually. matrix argument separator
[16:52] <mamund> yes, now you get it
[16:53] <cybernd> but: rest is based on using urls - and url tread ? special
[16:53] <mamund> would your answer be diff if the ";" was a "?" instead?
[16:53] <cybernd> in case of ? i would anser "/location"
[16:53] <mamund> it's a nice idea, but will not work out in the long run
[16:53] <mamund> REST has no interest in the various bits of teh URI
[16:53] <mamund> only that there is a URI
[16:54] <mamund> /weather-today/, /weather/2010-07-06
[16:54] <cybernd> yes but for a uri the portion after ? is the query
[16:54] <mamund> for HTTP URIs,
[16:54] <mamund> not for FTP
[16:55] <cybernd> both are the same uri syntax
[16:55] <mamund> ok
[16:55] <cybernd> ftp or http is just the scheme portion of the uri syntax
[16:55] <jsled> the scheme defines how the rest of the URL is interpreted.
[16:55] <jsled> (roughly)
[16:55] bigbluehat (~byoung@adsl-71-143-157.gsp.bellsouth.net) left irc: Quit: bigbluehat
[16:57] <mamund> jsled: my point here is that the "?" does not mark the end of a "resource" and the start of the "query"
[16:57] <mamund> cybernd has pointed out that many writers and toolsets, however make this very claim
[16:58] <mamund> do i have that about right cybernd?
[16:59] <cybernd> not sure - my words are to fuzzy to be interpreted :D
[16:59] <mamund> yeah, that's ok. same here
[16:59] <jsled> Er, isn't that exactly waht the '?' does?
[16:59] <mamund> i was trying to make a point that the actual "bits" of the URI are not so interesting to REST
[16:59] <cybernd> my own understanding currently would be - the whole thing including scheme and query is an URI, but only the path portion of the uri is significant to identify an rest call
[17:00] <mamund> yeah, i'm not ready to support that last statement
[17:00] <jsled> Really, looking at RFC1738 (which is probably superceeded), it's <path>?<searchpart> , not "resource".
[17:00] <mamund> yes, my point exactly
[17:00] <jsled> the overall URL is the URL.
[17:01] <mamund> and the UR[I|L] can be mapped to a resource on the server
[17:01] <cybernd> the german site has a nice diagram of it at the top (thats in english): http://de.wikipedia.org/wiki/Uniform_Resource_Identifier
[17:07] <mamund> well, at some point this turns into "shed painting" i guess....
[17:08] <mamund> as long as you can get your toolset to map the URI request to the right portion of your server-side code...
[17:08] <fu-manchu> as the maintainer of an HTTP server implementation, I can verify that the query portion is definitely part of the identity
[17:08] <mamund> you're doing fine. what i think it's called is not important.
[17:08] <fu-manchu> we had quite a long fight over that ;)
[17:08] <mamund> common, i think.
[17:08] <mamund> fu-manchu: how did this affect the implementation details for you?
[17:09] <darrelmiller_> I think part of the confusing is related to the fact that the URI spec changed the definition in one of the revisions. Let me try and dig up links.
[17:09] <fu-manchu> it mostly affected caching
[17:09] <mamund> IOW, what choices did you have to make and how did you go about it?
[17:10] <mamund> i am very interested in these kinds of moments in the life of an implementatio.
[17:11] <fu-manchu> and I will say that, although the URI must include the query portion (to the point that changing the order of query args ideally refers to a different resource), that doesn't necessarily mean your handler implementation can't use the same controller code to handle ?a=3&b=4 the same as ?b=4&a=3
[17:13] mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) left irc: Quit: mhausenblas
[17:14] fu-manchu is trying to find those old tickets
[17:14] <mamund> fu-manchu: i almost always make the order of the query portion irrelevant.
[17:15] <fu-manchu> yeah, it's become expected
[17:15] <mamund> IOW, you can switch order and not break the mapping to server-side code.
[17:15] <fu-manchu> even in cache implementations
[17:15] <mamund> yeah, this switch might result in a new cache entry, but that is...
[17:15] <mamund> orthagonal to my "
[17:15] <mamund> controller" coding
[17:16] <mamund> caching is often not even a part of my code, but handled by a reverse-proxy in my DMZ
[17:16] <mamund> squid up front
[17:16] graste (~graste@g225130165.adsl.alicedsl.de) joined #rest.
[17:16] <mamund> but your point is that the entire URI is used to make the mapping at runtime, right?
[17:18] <fu-manchu> my point is that the entire URI is used to identify the resource--whether your mapping maps multiple URI's to the same handler is orthogonal
[17:18] <darrelmiller_> Here it is. Compare section 3.4 in RFC 2396 that says "The query component is a string of information to be interpreted by the resource"
[17:19] <darrelmiller_> to section 3.4 in RFC 3986 which says "The query component contains non-hierarchical data that, along with data in the path component (Section 3.3), serves to identify a resource within the scope of the URI's scheme and naming authority (if any)."
[17:19] <mamund> fu-manchu: understood. that sounds like the same way i approached it.
[17:19] <darrelmiller_> http://www.ietf.org/rfc/rfc2396.txt http://www.ietf.org/rfc/rfc3986.txt
[17:19] <mamund> thanks darrelmiller
[17:19] <darrelmiller_> To me those are hugely different definitions of what a query string is for.
[17:20] <darrelmiller_> mamund: I'll save those links and add it to the FAQ in the wiki.
[17:21] <mamund> very cool.
[17:21] fu-manchu hates it when he can't find the right ticket on his own project
[17:22] <mamund> hee
[17:26] <fu-manchu> here's the thread in which I reversed my thinking on this subject: http://groups.google.com/group/cherrypy-devel/browse_frm/thread/76a3b9c53b2996a9/2257e5b247e6e2bd?hl=en_US&lnk=gst&q=query#2257e5b247e6e2bd
[17:27] <fu-manchu> so my first few posts in that thread are misguided--don't read them too closely
[17:28] <mamund> thanks fu-manchu
[17:30] <mamund> BTW - CherryPy is not listed at http://code.google.com/p/implementing-rest/wiki/RESTFrameworks
[17:30] <mamund> fu-manchu: would you be interested in maintaining a wiki page for CherryPy there?
[17:31] <fu-manchu> I'll look into it
[17:32] <mamund> would be very nice to have more python examples at that site
[17:32] <fu-manchu> I recently had a volunteer take a crack at a page on REST for our docs; if I can polish it up, maybe we can post it on that site too (?)
[17:33] <mamund> sure
[17:33] <fu-manchu> haha love the Sinatra page
[17:33] <mamund> LOL
[17:33] <mamund> as you can see, most times, it's a simple placeholder page
[17:34] <mamund> the matrix compare table is quite handy, too.
[17:34] <mamund> i can add you as a contributor to the wiki and then you can add a page and link it into the list.
[17:34] <mamund> updating the mtrix is pretty simple, too.
[17:35] <mamund> after that it's entirely up to you as to how much you want to add/expance
[17:35] <mamund> email me at mamund AT yahoo DOT com and i can get you (or anyone else) up
[17:35] <mamund> thanks'
[17:35] <mamund> fu-manchu: are you located in San Diego?
[17:36] <fu-manchu> yup
[17:36] <fu-manchu> still lovin' the "June gloom" in July
[17:36] <mamund> hee
[17:37] <mamund> i recall enjoying the weather out there (been about 10yrs since my last long visit, tho)
[17:39] <fu-manchu> here's the nugget of the changes for CP: http://groups.google.com/group/cherrypy-devel/msg/0fcc62df334bc9ed?hl=en_US
[17:39] <fu-manchu> where I said: "I wanted the REST concept of "resource" to map
[17:39] <fu-manchu> more or less to the CherryPy concept of "exposed callable", but I can
[17:39] <fu-manchu> see now that it doesn't and can't. It *does* map to the (callable,
[17:39] <fu-manchu> request.querystring) tuple."
[17:40] <fu-manchu> that resulted in 1) some terminology changes
[17:40] <fu-manchu> but also 2) a more liberal view on how to map URI's to handlers
[17:41] <fu-manchu> previously, we had been mostly stuck on the 'tree of objects' approach to mapping
[17:41] <fu-manchu> where /path/to/foo calls an object at path.to.foo()
[17:41] <fu-manchu> but after that point, we started building ways for people to prefer other modes of dispatch
[17:42] <mamund> yes, i went along this path, too.
[17:42] <fu-manchu> e.g. regex-based, or whatever they could imagine
[17:42] <mamund> yep - i use regex almost exclusively now.
[17:42] bigbluehat (~byoung@64.241.37.140) joined #rest.
[17:42] <fu-manchu> well I still hate regexes ;) but we made it easier for people to use that approach in CP
[17:44] <mamund> yep, i get that alot.
[17:44] <fu-manchu> partly due to the "new view" query-as-identifier that RFC 3986 clarified
[17:48] <mamund> it's the first sentence of 3.3 that seals it for me:
[17:48] <mamund> " The path component contains data, usually organized in hierarchical
[17:48] <mamund> form, that, along with data in the non-hierarchical query component
[17:48] <mamund> (Section 3.4), serves to identify a resource within the scope of the
[17:48] <mamund> URI's scheme and naming authority (if any)."
[17:53] <fu-manchu> http://article.gmane.org/gmane.comp.web.services.rest/319 sealed it for me :)
[17:54] <mamund> yeah, i saw that one, too.
[17:54] <fu-manchu> funny how that also applies to the recent long debate regarding conneg ;)
[17:54] <mamund> Roy has a way of focusing right in on the essential bit
[17:54] <mamund> yes!
[17:58] twilliams_ (41decaca@apache/committer/twilliams) left irc: Ping timeout: 252 seconds
[18:58] twilliams_ (41decaca@apache/committer/twilliams) joined #rest.
[19:42] twilliams_ (41decaca@apache/committer/twilliams) left irc: Quit: Page closed
[20:56] bigbluehat (~byoung@64.241.37.140) left irc: Quit: bigbluehat
[21:31] cybernd78 (~cybernd@85-127-56-90.dynamic.xdsl-line.inode.at) joined #rest.
[21:32] cybernd (~Miranda@193.178.208.8) left irc: Disconnected by services
[21:32] cybernd78 -> cybernd
[22:31] graste (~graste@g225130165.adsl.alicedsl.de) left irc: Quit: That you're not paranoid doesn't mean, they aren't right behind you!
[22:58] mamund thinks it's been an interesting day. i'm out and headed home.
[23:18] yadnem (~yadnem@host217-43-87-125.range217-43.btcentralplus.com) joined #rest.
[23:55] yadnem (~yadnem@host217-43-87-125.range217-43.btcentralplus.com) left irc: Quit: yadnem
[00:00] --- Wed Jul 7 2010