[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] 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] 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] Action: 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] cybernd: if i understand your Q, you can set whatever rules you want on how the server interprets the URI [14:42] is this about how to communicate to clients that some parts are optional or ... [14:42] 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] is it about implementation details on the server-side? [14:43] so this is a server-side coding issue RE the tools you're working with [14:43] 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] the "rest api" of what toolset? [14:44] 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] the rest api of my own toolset im developing :) [14:45] Joeconyers (~Joe@ool-182fafef.dyn.optonline.net) joined #rest. [14:46] ok [14:46] 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] ahhh [14:46] well, that's a JAX-RS issue. [14:46] the question is: is it a jax-rs limitation or something which should be avoided [14:47] FWIW, my own toolset uses regex in a manner you allude to [14:47] because some dotnet tools have the same limitations [14:47] this is about tools, not HTTP or RESTE [14:47] nope about rest [14:47] the basic question is: should /a/1 be treated as different resource as /a/1/b/2 [14:47] sure, it's a diff "resource" [14:48] is this one resource with one optional parameter, or are these 2 different resources [14:48] but is that really the Q? [14:48] diff resources. [14:48] why is this an important question for you? [14:48] (sorry, i came in late maybe) [14:48] 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] was just not sure if this shall be treated as optional parameter or not [14:49] i understand. [14:49] its an important question to understand the true meaning of "resource" in rests context [14:49] I think the server side implmentation issue is, should this be handled by one or two controllers. [14:50] not onle this - think about documentation [14:50] When server side frameworks start to introduce their notion of a "resource" you start to run into issues. [14:50] this implies also that there need to be 2 ressources documented instead of one with one optional portion of the parameter [14:51] For example, /foo and /foo?q=1 are two different resources, but many frameworks would handle these with the same "resource controller" [14:51] this means that the url parameters behind ? are also treated as significant for resource distinction? [14:51] Yes [14:52] damn :D i hoped that the resource ends on the left side of the ? [14:52] :-) I know, in some we ways I think we all wished it worked like that. But it doesn't. [14:52] my main issue is simply developer vs spec :) [14:53] 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] 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] Client dev or server dev? Server dev is free to parse away. [14:54] somehow related question in this context - given is a uri spec "/a/1" while there are only nubers allowed as last parameter [14:55] is it expected to have a 400 or a 404 if someone tries to call /a/myBad1 [14:55] I would say 404, personally. [14:56] jax-rs default is 404 in this case [14:56] my personal feeling was: thats odd i want to throw my own custom error in case of a malformed parameter [14:57] as always: thx for your feedback [14:57] The problem is how could the client have known it was supposed to be an int? [14:58] exactly [14:58] 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] 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] which would most probably be more valuable as feedback for the client dev [15:02] There is nothing to stop you returning descriptive information in the entity body when you return the 404. [15:03] 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] in other words: i need to accept the request in order to throw a 404 after i found the resource [15:04] Do you mean you can't easily return custom content in the body? [15:04] I understand. [15:05] but thats only a minor "definition" problem - easy to bypass in code - it just feels odd again [15:07] 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] really a bummer when toolsets get in the way [15:07] *cough* WCF *cough* [15:08] i run into many cases where devs are "lead" down the path of "least resistance" for the toolset... [15:08] and that results in terrible implementations [15:08] WCF, ASP.NET MVC, the list goes on. [15:08] even more annoying is when folks _try_ to built RESTful implementations.. [15:09] mamund: You mean like all these frameworks that automagically support generic XML and JSON but no other media-type! [15:09] and run into blockers like cybernd is describing... [15:09] sometimes the result is devs decide REST is a bad idea! [15:09] darrelmiller: just one of the many annoyances [15:09] i find URI Handling and Routing one of the most annoying - [15:09] just as cybernd describes [15:10] it makes simple implementations so frustrating [15:10] toolsets should not be messing w/ cybernd's optional args! [15:10] Or my other favourite pet peeve. Using the same controller to handle both lists of entities and the single entities. [15:11] hmm im not sure mamund [15:11] in this case its a java jsr and often the jsr's are rock solid because they allow only really interoperable stuff [15:11] mamund: I thought you were happy with the regex style routing? What part of framework routing bugs you? [15:11] 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] 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] (i got no clue about ruby support - just an example - just a language i did not thought about) [15:13] 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] 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] 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] I regularly use optional parameters in URIs. [15:16] using /a/1 or ?a=1 [15:16] e.g. /Customer/3/ContactInfo /Customer/layout [15:16] Both... [15:17] thx [15:17] or /Customer/3?viewOnly=true [15:18] 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] 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] cybernd: /location;39.1.0,84.36.2 [16:49] what's the resource? [16:51] i think the full thing "/location;39.1.0,84.36.2" [16:52] why? [16:52] because ; has no special meaning [16:52] you might tread it special in your ap as parameter seperation, but basically it has no special meaning for the url definition [16:52] well, it does actually. matrix argument separator [16:52] yes, now you get it [16:53] but: rest is based on using urls - and url tread ? special [16:53] would your answer be diff if the ";" was a "?" instead? [16:53] in case of ? i would anser "/location" [16:53] it's a nice idea, but will not work out in the long run [16:53] REST has no interest in the various bits of teh URI [16:53] only that there is a URI [16:54] /weather-today/, /weather/2010-07-06 [16:54] yes but for a uri the portion after ? is the query [16:54] for HTTP URIs, [16:54] not for FTP [16:55] both are the same uri syntax [16:55] ok [16:55] ftp or http is just the scheme portion of the uri syntax [16:55] the scheme defines how the rest of the URL is interpreted. [16:55] (roughly) [16:55] bigbluehat (~byoung@adsl-71-143-157.gsp.bellsouth.net) left irc: Quit: bigbluehat [16:57] jsled: my point here is that the "?" does not mark the end of a "resource" and the start of the "query" [16:57] cybernd has pointed out that many writers and toolsets, however make this very claim [16:58] do i have that about right cybernd? [16:59] not sure - my words are to fuzzy to be interpreted :D [16:59] yeah, that's ok. same here [16:59] Er, isn't that exactly waht the '?' does? [16:59] i was trying to make a point that the actual "bits" of the URI are not so interesting to REST [16:59] 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] yeah, i'm not ready to support that last statement [17:00] Really, looking at RFC1738 (which is probably superceeded), it's ? , not "resource". [17:00] yes, my point exactly [17:00] the overall URL is the URL. [17:01] and the UR[I|L] can be mapped to a resource on the server [17:01] 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] well, at some point this turns into "shed painting" i guess.... [17:08] as long as you can get your toolset to map the URI request to the right portion of your server-side code... [17:08] as the maintainer of an HTTP server implementation, I can verify that the query portion is definitely part of the identity [17:08] you're doing fine. what i think it's called is not important. [17:08] we had quite a long fight over that ;) [17:08] common, i think. [17:08] fu-manchu: how did this affect the implementation details for you? [17:09] 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] it mostly affected caching [17:09] IOW, what choices did you have to make and how did you go about it? [17:10] i am very interested in these kinds of moments in the life of an implementatio. [17:11] 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] Action: fu-manchu is trying to find those old tickets [17:14] fu-manchu: i almost always make the order of the query portion irrelevant. [17:15] yeah, it's become expected [17:15] IOW, you can switch order and not break the mapping to server-side code. [17:15] even in cache implementations [17:15] yeah, this switch might result in a new cache entry, but that is... [17:15] orthagonal to my " [17:15] controller" coding [17:16] caching is often not even a part of my code, but handled by a reverse-proxy in my DMZ [17:16] squid up front [17:16] graste (~graste@g225130165.adsl.alicedsl.de) joined #rest. [17:16] but your point is that the entire URI is used to make the mapping at runtime, right? [17:18] 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] 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] 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] fu-manchu: understood. that sounds like the same way i approached it. [17:19] http://www.ietf.org/rfc/rfc2396.txt http://www.ietf.org/rfc/rfc3986.txt [17:19] thanks darrelmiller [17:19] To me those are hugely different definitions of what a query string is for. [17:20] mamund: I'll save those links and add it to the FAQ in the wiki. [17:21] very cool. [17:21] Action: fu-manchu hates it when he can't find the right ticket on his own project [17:22] hee [17:26] 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] so my first few posts in that thread are misguided--don't read them too closely [17:28] thanks fu-manchu [17:30] BTW - CherryPy is not listed at http://code.google.com/p/implementing-rest/wiki/RESTFrameworks [17:30] fu-manchu: would you be interested in maintaining a wiki page for CherryPy there? [17:31] I'll look into it [17:32] would be very nice to have more python examples at that site [17:32] 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] sure [17:33] haha love the Sinatra page [17:33] LOL [17:33] as you can see, most times, it's a simple placeholder page [17:34] the matrix compare table is quite handy, too. [17:34] 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] updating the mtrix is pretty simple, too. [17:35] after that it's entirely up to you as to how much you want to add/expance [17:35] email me at mamund AT yahoo DOT com and i can get you (or anyone else) up [17:35] thanks' [17:35] fu-manchu: are you located in San Diego? [17:36] yup [17:36] still lovin' the "June gloom" in July [17:36] hee [17:37] i recall enjoying the weather out there (been about 10yrs since my last long visit, tho) [17:39] here's the nugget of the changes for CP: http://groups.google.com/group/cherrypy-devel/msg/0fcc62df334bc9ed?hl=en_US [17:39] where I said: "I wanted the REST concept of "resource" to map [17:39] more or less to the CherryPy concept of "exposed callable", but I can [17:39] see now that it doesn't and can't. It *does* map to the (callable, [17:39] request.querystring) tuple." [17:40] that resulted in 1) some terminology changes [17:40] but also 2) a more liberal view on how to map URI's to handlers [17:41] previously, we had been mostly stuck on the 'tree of objects' approach to mapping [17:41] where /path/to/foo calls an object at path.to.foo() [17:41] but after that point, we started building ways for people to prefer other modes of dispatch [17:42] yes, i went along this path, too. [17:42] e.g. regex-based, or whatever they could imagine [17:42] yep - i use regex almost exclusively now. [17:42] bigbluehat (~byoung@64.241.37.140) joined #rest. [17:42] well I still hate regexes ;) but we made it easier for people to use that approach in CP [17:44] yep, i get that alot. [17:44] partly due to the "new view" query-as-identifier that RFC 3986 clarified [17:48] it's the first sentence of 3.3 that seals it for me: [17:48] " The path component contains data, usually organized in hierarchical [17:48] form, that, along with data in the non-hierarchical query component [17:48] (Section 3.4), serves to identify a resource within the scope of the [17:48] URI's scheme and naming authority (if any)." [17:53] http://article.gmane.org/gmane.comp.web.services.rest/319 sealed it for me :) [17:54] yeah, i saw that one, too. [17:54] funny how that also applies to the recent long debate regarding conneg ;) [17:54] Roy has a way of focusing right in on the essential bit [17:54] 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] Nick change: 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] Action: 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