[00:11] Action: mamund has frittered away enough time here. ta! [00:13] Later Mike. [00:47] KevBurnsJr (~kevburnsj@c-67-161-65-81.hsd1.ca.comcast.net) left irc: [02:48] avdi (~avdi@c-174-55-88-101.hsd1.pa.comcast.net) joined #rest. [02:49] avdi (~avdi@c-174-55-88-101.hsd1.pa.comcast.net) left irc: Client Quit [03:44] .title http://statuscodedrinkinggame.com/ [03:44] Can't connect to http://statuscodedrinkinggame.com/ [06:29] algermissen (~algermiss@p549060E5.dip.t-dialin.net) joined #rest. [06:59] ordnungswidrig1 (~Adium@p5B1745B1.dip.t-dialin.net) joined #rest. [07:02] ordnungswidrig (~Adium@p5B173E4E.dip.t-dialin.net) left irc: Ping timeout: 276 seconds [07:04] algermissen (~algermiss@p549060E5.dip.t-dialin.net) left irc: Quit: RESTing [07:16] algermissen (~algermiss@p549060E5.dip.t-dialin.net) joined #rest. [07:34] KarlHungus (ssanders@for.my.n1gs.net) left irc: Ping timeout: 260 seconds [07:37] algermissen (~algermiss@p549060E5.dip.t-dialin.net) left irc: Quit: RESTing [07:38] Nick change: ordnungswidrig1 -> ordnungswidrig [07:42] mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) joined #rest. [07:54] KarlHungus (ssanders@for.my.n1gs.net) joined #rest. [07:56] algermissen (~algermiss@p549060E5.dip.t-dialin.net) joined #rest. [07:57] algermissen (~algermiss@p549060E5.dip.t-dialin.net) left irc: Client Quit [08:14] algermissen (~algermiss@p549060E5.dip.t-dialin.net) joined #rest. [08:19] algermissen (~algermiss@p549060E5.dip.t-dialin.net) left irc: Quit: RESTing [08:23] algermissen (~algermiss@p549060E5.dip.t-dialin.net) joined #rest. [08:46] ramsey (~ramsey@unaffiliated/ramsey) got netsplit. [08:47] ramsey (~ramsey@unaffiliated/ramsey) returned to #rest. [09:33] algermissen (~algermiss@p549060E5.dip.t-dialin.net) left irc: Quit: RESTing [09:43] algermissen (~algermiss@p549060E5.dip.t-dialin.net) joined #rest. [09:44] algermissen (~algermiss@p549060E5.dip.t-dialin.net) left irc: Client Quit [09:45] algermissen (~algermiss@p549060E5.dip.t-dialin.net) joined #rest. [11:43] lol I keep giving this girl from one of the cloud vendors a hard time on her blog [11:43] they do 'Load Balancing' for elastic cloud/web apps [11:44] talking about how difficult it is to 'scale in' because of sessions.. [11:44] /facepalm [11:53] LOL [11:55] I love those facepalm images that also slightly express shame for mankind [11:57] http://i357.photobucket.com/albums/oo18/redsyndicate/ImpliedFacepalm.png [11:58] yeah - great [11:58] amazing how often a day you feel like that [12:00] algermissen (~algermiss@p549060E5.dip.t-dialin.net) left irc: Quit: RESTing [12:07] algermissen (~algermiss@p549060E5.dip.t-dialin.net) joined #rest. [12:15] KevBurnsJr (KevBurnsJr@c-69-181-187-21.hsd1.ca.comcast.net) joined #rest. [12:17] mamund: uri template parser is coming along [12:17] http://github.com/KevBurnsJr/php-uri-template-parser [12:18] http://php-uri-template-parser.hackyhack.net/tests.php [12:18] There [12:18] 's little in the spec about template matching [12:18] mostly it's : vars + tpl = uri [12:18] but I want to reverse map [12:19] tpl + uri = vars [12:19] that's my secret reason for writing it :P [12:20] 5am. staring to hallucinate. Time for bed. Just wanted to put in progress. [12:20] peace [12:20] KevBurnsJr (KevBurnsJr@c-69-181-187-21.hsd1.ca.comcast.net) left irc: Quit: hearing sounds that aren't there. [12:24] algermissen: Nice article on using DNS for service discovery at InfoQ. [12:26] algermissen: It is strange that you are getting so much pushback on it though. Isn't that pretty much what an MX record is all about. Find me the SMTP server for this domain. [12:27] algermissen: To claim that all service discovery is pointless because UDDI failed seems like throwing the baby out with the bath water. [12:48] bigbluehat (~byoung@adsl-71-189-114.gsp.bellsouth.net) joined #rest. [13:03] darrel: thanks [13:04] surprised by the pushbak, too [13:04] after all, it was just a summary of what one could do - nothing to fear actually [13:04] when I started, I was surprised that all the was already in place with dns-sd so it felt really handy [13:06] re: like MX rec - there is the additional indirection. It is more like: find me all MX servers for this domain and then second query for [13:06] find me the meta data for this or that instance [13:07] OTH, it is always good to be reluctant to adding stuff to an architecture :-) [13:07] But I found it more straight forward than using a new media type + a well known URI [13:09] ramsey: do you (or anyone else here) know of a good PHP-based AtomPub library? [13:13] algermissen: Yes I think it is definitely a better approach than new registry service at a well known URL. By doing that you are just adding another layer of indirection to the coupling. [13:17] algermissen: I use DNS for discovery but have a much easier scenario. I know there is only going to be one instance of my service within a single network so I hard code an URL such as http://tmserver:8700 in my client. I then use DNS to point to the server. This way the URL can be the same at all of my customers. (Assuming no-one else is using my port :-) ) [13:30] darrel: you might want to look at SRV records only. They come with port info directly so if you never have several services of a type on a single host/port then you are fine [13:31] I had an interesting other issue the other day: [13:31] The role that a server plays in an application really only exists once the application exists. [13:31] IOW, there can not really be a service type before you have an application [13:32] thinking this through leads to the 'type of service' being more like 'type of application' [13:32] the DNS queryt would mean sth like: find me all instances of a search application entry URI in this domain [13:32] and not: find me all search services [13:33] "Service" is such a loaded and overloaded term. [13:34] HA! yes. Service is an OO-term. In REST there is no idea of 'service' [13:35] I feel the same way about the term REST API. It just doesn't make sense to look at a RESTful system from just the server side. [13:36] service is a contractual term [13:37] it's actually quite an important term too [13:37] :P [13:38] bigbluehat: I'm (very slowly) writing one. :-) [13:38] As I said, it is an overloaded term. ;-) [13:38] bigbluehat: Other than that, no, I don't know of one. [13:39] darrelmiller: I agree. REST is something that comprises the entire network, not just the server. [13:44] right - it's about building systems [13:44] ramsey: I think that is one of the bigger conceptual leaps that people need to make when trying grok REST. [13:44] it doesn't just effect what 'service' means it also has a massive effect on what integration actually entails [13:45] People are so used to visualizing distributed systems being seperated by these API style de-coupling points, that we try and use the same mental model when talking about REST systems. [13:45] Hi guys [13:46] yepp - this is where I am mentally right now [13:46] integration is not system A talking to system B [13:47] but user X engaging in an application Y [13:47] X just interacts with the app on the basis of steady states [13:47] and the means to do this is a user agent [13:47] trying to map that to business processes [13:48] .... is every action of a process user an execution of a network application? [13:48] or is the whole process a multi-user networked appication? [13:53] ramsey: is that the Lithium based one? [13:53] avdi (~avdi@c-174-55-88-101.hsd1.pa.comcast.net) joined #rest. [13:56] bigbluehat: there are several incarnations. One was going to be just straight PHP designed after Abdera. Another was going to be a PECL extension designed after Abdera, and the third was Lithium-based, but I didn't get very far with it. [13:56] bigbluehat: I'll need to revisit it soon for work, actually. [13:56] bigbluehat: So, maybe I'll get some traction and actually finish one of those. :-) [13:57] bigbluehat: I'll probably go with writing the extension, but I'll write it very lightweight and for PHP 5.3, hopefully making it easily interoperable with Lithium, Symfony 2, Zend Framework 2, etc. [13:58] bigbluehat: I should draw up some ideas/plans, blow away my old github repos and get started on a new one that I open up for others to work on :-) [13:59] ramsey: I'd be happy to help [14:00] ramsey: not sure what I could contribute in way of a pecl extension, but would be happy to test it [14:00] ramsey: have you looked at pecl_http much? seems great, and could be the basis (or useful) in building an atom extension or even standalone PHP app [14:01] bigbluehat: Yeah, I've considered that as a basis or a dependency. [14:01] ramsey: I'd love to see that in more people's toolbelts [14:01] Action: mamund has arrived, let the party begin! [14:01] seems like a great extension [14:01] bigbluehat: Another option is to design/write it first in PHP using pecl_http and XMLReader/XMLWriter and then translate it into a PECL extension later. [14:01] ramsey: I could help with that. :) [14:02] bigbluehat: but, yeah, I definitely need help on it :-) [14:02] ramsey: I'm wanting full AtomPub support in our BlueInk CMS, so I'd be happy to contribute [14:02] bigbluehat: okay... I'll "restart" my repo later this week. If I haven't done anything by Friday, pester me about it. :-) [14:02] bigbluehat: can you use 5.3 with that CMS? [14:03] ramsey: BlueInk runs fine on PHP 5.3, but as yet doesn't *require* it [14:03] though, I'm fine if that's in its near future [14:03] Right. I mean, is it okay for this to require 5.3? [14:03] i.e. namespaces, closures, etc. are features I want to use in order for this to work best with the next generation of PHP frameworks [14:04] ramsey: I think so. we'll be upgrading our servers within the year, and I hope to encourage the others hosting BlueInk (as intranet apps) to move up to PHP 5.3 & install CouchDB :D [14:04] cool [14:04] ramsey: completely understand [14:04] ramsey: I've already convinced the intranet folks to put pecl_http in place, so hopefully Couch & PHP 5.3 won't be too hard ;) [14:04] hehe [14:04] I'm meeting with them today at 12, so I'll let them know what's coming. ;) [14:05] We're upgrading production to 5.3.2 in about 2 weeks [14:05] ramsey: for moontoast? [14:06] yes [14:09] ramsey: is XML(Reader|Writer) prefered to the other XML options PHP has? if so, why? (curious) [14:09] bigbluehat: by chance, will you be at tekx? [14:09] Preferred for speed. It's a SAX-based parser, rather than DOM. [14:09] It's on by default in all 5.x installations, too. [14:10] ramsey: sadly, no. My wife's getting her MFA in play writing and will be at her residency in Kentucky that week (or just after), so can't make it [14:10] Ah, sorry to hear for you, but good for her! :-) [14:10] indeed :) [14:12] KevBurnsJr: your uri-template implementation is looking good so far. (hopefully you're getting some sleep now) [14:12] mamund: where's that at? [14:13] ramsey: have you played with phpQuery at all? [14:13] uses the DOM in PHP, but it's a farily complete port of jQuery's API to PHP [14:15] bigbluehat: nope... never heard of it [14:15] Why would you want to port jQuery's API to PHP? [14:16] bigbluehat: KevBurnsJr included links in the channel here early today. check here: http://rest.hackyhack.net/2010-05-05.html#41/h41 [14:17] algermissen: interesting article. FWIW, don't let the doubters sway your thinking. [14:17] ramsey: server-side DOM parsing for templates and such, or screenscarping [14:17] ramsey: you then have pure HTML fragments that can be used elsewhere with various phpQuery parsing to have them contain different content, etc (think CMS ;) ) [14:18] mamund: nah - never :-) [14:18] mamun: thanks. taking a look [14:20] KevBurnsJr: what are your thoughts on Recess (the PHP framework) [14:21] algermissen: as an early UDDI adopter and promoter (/me hangs his head), i can see your solution is _nothing_ like UDDI and is much more open, flexible, and usable. [14:22] also, IMO, the whole "service discovery" meme trips switches in some folks' heads and generates instant reactions w/o thinking through the details. [14:22] i see this happen if someone uses the word "transaction" in the same sentence as "REST", too. [14:23] true [14:24] anyway, good idea; well-written article, too. [14:25] hey, thanks! Already planning a follow up :-) [14:25] But it takes time to write such things (me at least) [14:26] when I wrote the article, I still thought in terms of services... [14:26] now I think in terms of applications [14:27] so the title should be more like "Using DNS for networked application entry URI discovery" [14:27] ... which makes me scratch my head :-) [14:28] Service are not really aware of the nature of the applications they participate in ... [14:28] algermissen: you know, i was thinking about this as i read your article... [14:29] when you apply DNS to RESTful apps, you really see that (someone said is earlier here today) programming in REST is programming _the_entire_network_ [14:29] and, when programming the network, DNS is a vital component, IMO. [14:30] i think DNS is one of the most successful of the app-level network protocols... [14:30] and it's not leveraged enough. your article shows just one way to re-think that protocol, IMO. [14:30] ah - "Rethinking DNS" what a slick title :-) [14:31] Let me try another wording.... [14:31] Looking at the title "Search Engines" of my bookmark folder for search engines.. [14:31] what does "Search Engines" identify? [14:31] A kind of REST application? [14:32] Certainly *not* a service type [14:33] Because it is not me that uses the server - the user *agent* uses the server. I just use the application. [14:33] So what I look for is entry URIs for apps, not service URIs [14:33] yes, interesting line of thinking. [14:34] "search" is an app, then. [14:34] Yep [14:34] i've been thinking along the lines that every "app" i add to the network is just a "component" or some other phrase [14:34] "the app is the net" maybe [14:35] hmm - question: what does it mean to 'add an app'? [14:35] it's easy to see that adding my HTML page is just one more "page" on the web. [14:35] if i add an "app", what am i adding? [14:35] step back.. [14:35] well, i program the network (that's my app) [14:35] k [14:35] app vs app execution instance [14:35] uhhh [14:36] not following [14:36] does an app exist in the absence of its own execution? [14:36] shivering [14:37] ok, no. [14:37] ah - to me: yes [14:37] Example: [14:37] ok [14:38] Apps are implemented by user agents [14:38] algermissen: I think it is more valuable to consider each interaction "01an execution of a network application". It keeps you focused on stateless interactions. [14:38] Browsers implement one app - downloading a web page? [14:38] s/?/"/ [14:39] when a user enters a URI in the browser it startes the app [14:39] the user agent executes the app towards the next steady state [14:39] which is the Web page [14:39] the human interpretation on top is [14:39] misleading because we think it is part of the app - but it is not [14:40] yech - that is confusing [14:40] because I am still working on it myself [14:40] ] [14:41] Very hard to get the human mind out of the way [14:41] because we are so biased by it since it is he only REST use there is [14:41] (even AtomPub is eventually human targetted) [14:42] Hmm - need to sort my brain I guess. [14:43] There seems to be something in the direction of building blocks for apps and apps [14:43] user uses the building blocks (the steady states if you want) [14:44] and creates the actually application instance while steping through it [14:44] but inside the user agent -to- server(s) automatic progress there are the 'building blocks' moving [14:45] bah - will stop. This leads nowhere right now (sorry) [14:45] general comment: the "app vs. app instance" strikes me as a tautology that applies to all things. e.g. "the map is not the territory" [14:46] IOW, i don't find it helpful to point this out most of the time. [14:46] consider this: [14:46] buying a book on the Web is an app [14:46] where is that app realized? [14:47] in your brain? In your browser? [14:47] in the steady states? [14:47] heheh.... [14:47] do you start the app? or is it just there all the time? [14:48] being more blunt: why is this difference (app vs. app instance) important? [14:48] dunno :-) [14:48] aha! [14:48] pushing the metaphysical implications of the question... [14:49] I am just a bot consuming your time with philosophical distractions :-) [14:49] all of your life is a mere representation of reality. where is the app now, grasshopper? [14:49] [14:49] I am the app - and time is it's execution [14:50] Its likely more a matter of model and reality, not of type/instance [14:50] consider a buying a book use case [14:50] at the modeling level [14:50] how and where is it realized? [14:51] IMO: by combination of user intent and user agent implementation [14:51] and if there is no user intent: only by the user agent (see MOMspider for example) [14:52] 'checking site for dangling links' is the use case realized by Roy's MOMspider [14:52] no user involvement (except starting it) [15:03] Hmm, any thought about URN vs. URI vs. URL? I have business model, say products, product catalog, order etc. When I post a order-representation to a order-inbox-resource shall the product be referenced by a URL or by a URN? [15:03] what's the pro's and con's? [15:06] ordnungswidrig: is this for internal storage or external representations? [15:07] mamund: good point. internal I don't really care because I'll have to do some mapping to a db-key anyway. [15:07] mamund: I care more about moving servers and changing urls [15:07] ok [15:08] mamund: that a representation of product no. 2203 is available at http://text/products/2203 is accidental. [15:08] well, temporal at least, right? [15:09] mamund: right, I can translate to a internal id at request time. [15:09] this doc might help you decide: http://www.w3.org/TR/uri-clarification/ [15:09] I wonder if I get benefits in using urns or urls-as-uri to identify products. This would work in a REST-over-STMP scenario as well [15:10] I read the paper but I came to the conclusion that there is no private URN scheme, right? [15:11] private? [15:11] unregsitered, like private mime types: text/vnd.com.mydomain+xml [15:12] mamund: I know that I can use a http URL as a URI like xml schema does but this encourages people to try to "access " the URL [15:12] you can create URN details the same way you do URI details [15:12] ohhh.... [15:12] you mean minting URIs that can't be dereferenced, then? [15:14] mamund: yes. or that can be dereferenced by the server only (which it must be able to). [15:15] well, not sure about that last comment about who can deref the URI but... [15:16] i use URNs within representations for things that i want to be unique, but don't want the client to attempt to de-ref. [15:16] i treat the URN scheme as my "internal map" moniker in representations (if that makes sense) [15:16] mamund: like xml processing applications that have a resolver that can resolve the ns uri for certain schemata to a locally stored copy of the schema declaration [15:16] ok, so a URI that is not a URL might by the way to go then? [15:18] yeah, as in URN. [15:18] so why not an URN [15:19] a URN _is_ a URI that is not a URL [15:21] sorry, ordnungswidrig, maybe i've lost the plot here and confused both of us. [15:21] in my head, URL is a de-reference-able item, URN is not. both are URIs. it's how i have them arranged in my head. (maybe that's not correct?) [15:25] bigbluehat (~byoung@adsl-71-189-114.gsp.bellsouth.net) left irc: Quit: bigbluehat [15:25] sorry, it was me that was confused by URN<->URL [15:26] but you can _resolve_ a URN to a URL, right? [15:27] ok, i understand. [15:28] if you're using the URN scheme, i don't know of any clients that resolve that to a place "on the web" if that's the Q. [15:40] ok, but resolving a URN is a concept that exists, right? [15:40] yes [15:43] ok, I'll use URN to identify my business entities which I resolve to URL which accept and return representations... [15:45] mhausenblas (~mhausenbl@wg1-nat.fwgal01.deri.ie) left irc: Quit: mhausenblas [15:58] ordnungswidrig: this might give you some hints on how folks were thinking about writing URN resolvers: http://tools.ietf.org/html/rfc2169 [16:00] mamund: oh yes, I now that. could be useful, as well as a server the can resolve URN to it's private internal representation (e.g. db key) itself [16:01] s/the can/that can/ [16:03] yep. mostly historical stuff there, was listed as experimental and is from '97. [16:12] hmm, all I can found about resolving URNs is about a closed set of URNs, like in the oasis URN schema, but I guess there is nothing to say against URL templating when resolving a URN to a URL. so urn:vnd:example.test:products:{productId} -> http://erp.example.test/here/are/the/products/{productId} [16:21] yeah, the point is that you are in charge of documenting the custom resolver. [16:22] you can tell clients (agents) that they need to be able to do this... [16:22] or you can tell servers they need to do this. [16:22] if you are really serious, you can register the NID w/ IANA, too. [16:23] hmm, regarding a web shop workflow: the server sends a catalog repr with urls to products, the client "stores" product url in it's cart and posts the cart-representation to the order inbox resource [16:23] so URNs are internal only [16:24] or the client extracts the product URN from the product resource representation and posts the URNs in a cart representation to the server. [16:24] The latter would enable to post a cart to a server that was not aware of the product resource of the catalog server [16:26] well, even when using URLs, the server that receieves the cart need not "know" about the products. they could have come from some other server(s) [16:27] so why having URNs when there are unresolvable URLs? [16:30] well, they need not be unresolvable to still be "unknown" to the target server, right? [16:31] the target server will only be able to handle dereferncable URIs because it needs to get a price quote and title form the catalog server, e.g. [16:32] ahh [16:32] ok [16:32] bradley-holt (~bradley-h@65-183-135-35-dhcp.burlingtontelecom.net) joined #rest. [16:32] so either URN -> URL or http-URL-as-URI -> URL will work. [16:32] yep [16:33] but the latter will lead people to skip the URI resolution and try to _use_ the URI as a URL [16:33] again, if you use a URN you can also document a method for de-refrencing them using a custom resolver. [16:33] well, what people are "led" to and all is kinda outside your control. [16:37] mamund: but the usage of http-URLs as URIs led to kind of ddos agains the w3c servers because of dumb xml processors which downloaded the file every time [18:08] bigbluehat (~byoung@64.134.182.242) joined #rest. [18:20] insanekane (~kane@116.68.73.149) joined #rest. [18:22] ordnungswidrig: was away for a while... [18:23] me also :-) [18:23] just returned [18:29] mamund: time for another subject to talk about? [18:33] hehehe [18:33] sure [18:38] one can have authentication at the transport level (http auth) or at the representation level. For an order processor you can secure it with http authentication or you can digitally sign the order request representation that you post. right? [18:38] the latter is latter is uncomment with REST as far as I can see [18:39] s/uncomment/uncommon/ [18:43] if i understand you, neither is related to REST directly... [18:43] transport auth is HTTP-related (as a layer) [18:44] signing either bodies or URIs is "an implementation detail" and not protocol or arch-style specific [18:44] does that make sense? [18:45] mamund: well, not related to REST is a good point. I just came to the insight that authenticating at transport level will make authentication more lightweight because you must not take the content into account. [18:46] however you cannot forward the request further to another system to process the request because you cannot forward the authentication itself. [18:47] yeah, that's a good way to look at it... [18:47] hmm, but for GET request you must authenticat at the request / protocol level... [18:48] i use transport auth to set the identity of the user [18:48] brb [18:48] i use other forms of encryption to ensure the integrity of the message [18:58] re [18:58] other forms? [18:59] at the protocol level? [19:03] keep in mind that auth affects cacheability so you need to do it at the HTTP level - The Authenticate header has distint meaning to caches. [19:04] i use TLS to encrypt the message... [19:04] i use in-message encryption as a way to sign certain parts of the message [19:06] algermissen: right. that is for get requests. in-message encryption is usable only for put/post [19:06] sorry if I missed that that has already been said. was away [19:07] i sometimes use URI signing to control lifetime or other details of the link, too. [19:07] mamund: ready for take two on the application issue? [19:07] control lifetime? [19:17] ordnungswidrig: yeah, link might only be valid for a limited length of time, might only work for X number of requests, etc. [19:17] algermissen: go for it! [19:18] application is 'created' through user's intent - the application is what the user makes of the steady states it accesses via the user agent [19:19] the media types and the user agent implementation (it's interpretation and assumptions of the media types)... [19:19] greatly affects the possible applications the user can actually 'execute' [19:19] KevBurnsJr (KevBurnsJr@c-69-181-187-21.hsd1.ca.comcast.net) joined #rest. [19:20] in that sense user agent implementations... [19:20] prescribe the kind or family of possible applications [19:20] MOMspider for example is a user agent.. [19:21] that implements only one application... [19:21] bigbluehat (~byoung@64.134.182.242) left irc: Quit: bigbluehat [19:21] because it never comes back with an intermediate steady state for the .. [19:21] user to actually make a decision that would change the application [19:22] web browsers are the other extreme for of user agents [19:22] because they come back with a steady state *very* often and make possible very many applications [19:22] such as buying a book or checking for availability of a book [19:22] or just checking its price [19:22] phew [19:23] so it is not just the media types that affect what apps are possible [19:24] also the user agent implementations affect that [19:24] Action: KevBurnsJr just missed bigbluehat [19:25] avdi (avdi@c-174-55-88-101.hsd1.pa.comcast.net) left #rest. [19:27] algermissen: i certainly agree with the final point: agent implementations are key (i often think of them as the limiting factor) in the implmentation of the app [19:29] and - do you at least understand what I mean in the previous points :-)? [19:31] algermissen: i think i understand it, but am struggling to grasp it's importance [19:33] The importance is to get an understanding of the significance of the individual elements (user, UA, media type, application).. [19:34] i see [19:34] to have a good basis for principled user agent and media type design [19:34] Media type design for example essentially affects the possible steady states you *can* have [19:35] Is the representation of a resource expected to be the same for put/post and get? (for the same media-type) [19:35] user agent design affects the steady states you *will* have (IOW - when the control is handed back to the user) [19:35] ordnungswidrig: no [19:37] so I can post a order-resource-representation which identifies products by an id and will get a representation which represents them by URLs to the a product resource? [19:38] server is free to do whatever it likes [19:39] I know. I was thinking about what would be good for clients [19:42] When a product in an order resource is represented by a URI then the server will have to parse the URI and translate it into an internal represenation, e.g. a db key. [19:44] ordering is not so easy [19:44] you basically need agreement about the item IDs [19:44] one way is sending them in form for client to select [19:45] If you have URIs for the items then telling the client about them in the order confirm is maybe good [19:45] but you need to tell it the mapping, too I guess. [19:46] algermissen: server offers a catalogue resource which contains the URIs of product, or they are available from a search resource. [19:46] Look at UBL item identification for more sophisticated stuff :-) [19:46] (I'll search link if you are interested) [19:46] I looked at UBL but the use URNs, right? [19:47] or better they use ids, right? [19:47] No - the use buyerItemIdentification, sellerItemIdentification, standardItemIdentification and they all can be strings or strings of a scheme [19:47] basically UBL uses whatever the parties agreed on to be used :-) [19:47] ok, so a ui would be a special kind of string [19:47] s/ui/uri/ [19:50] wonders why his tomcat for UBL catalog is down... [19:51] using URIs to identify a product might be a good idea, a rest http server typically knows how to deconstruct URIs and mapping URL to the part of code which "implements" a resouce is the core of a http server. [20:10] guys, another one. Do anybody know of a javascript lib to implement a RESTful client in the browser? Something that fetches resources, you can define how to react on a media type and so on. [20:14] i just use a custom ajax class i wrote and handle the details within my custom pages (accept, content-type, etag, etc.) [20:31] I thought of a state machine which transitions a triggered by the responses. However that would be unrestful because the client should react to any media type it knows. [20:35] ordnungswidrig: i've written lots of clients that only know one media type. [20:37] so the state transitions is handled how? [20:37] not sure of the Q [20:44] KevBurnsJr (KevBurnsJr@c-69-181-187-21.hsd1.ca.comcast.net) left irc: [20:47] hmm, I you can model the client as a state machine which reacts to the pages. Or the server is the state machine and the client's state is a simple linear list of URLs [20:47] mamund: you get the idea? [20:48] hmmm... not really. [20:49] ok [20:49] state transitions as in "how does the client now how to follow links?" [20:49] if that's the Q, i do this using link relations [20:50] if the client has a specific goal, i can learn the possible transitions from checking on the documented link relations and programming the client accordingly [20:51] let me try my latest epiphany :-) [20:51] ordnungswidrig: what is your use case? [20:51] as in "buying a book" [20:51] Action: mamund sits down and grabs a hold of his seat. [20:51] yeah - hold tight! [20:52] .. wonder how that works out: explaining rest from the other end [20:52] member:ordnungswidrig:? [20:53] bradley-holt (~bradley-h@65-183-135-35-dhcp.burlingtontelecom.net) left irc: Remote host closed the connection [20:53] why is it that people allways leave when I start to type? [20:54] heheheeh [20:54] trying again: ordnungswidrig - what is your use case (just the title I mean) [20:55] maybe ordnungswidrig did not grab a hold of his seat and is now on the floor? [20:55] ROFL [20:55] ok, try me!, try me! [20:56] :-) But I want to help *him* so he should be there (or she?) [20:56] him [20:56] yeah [20:56] i agree [20:57] waits...patiently [20:58] re [20:58] Action: mamund stares at the cieling, quietly whistling [20:59] ah! [20:59] sitting on my chair again [20:59] ah! so here it comes again - wipe out your brain (especially clear *all* OO concepts) [21:00] did not fall of, had to place the waste baskets on the street for pickup tomorrow :-) [21:00] I put it in the basket [21:00] what did you put in the basket? [21:01] anyway: ordnungswidrig: what is the title of your use case? [21:01] I put all OO concepts into a basket. Then I set the basket on fire. I'm more in FP, you know. [21:01] So the title of the use case [21:02] As a Customer I want to place an order in an web shop which is built as a javascript client talking to a rest over http server. [21:03] So the user is a human? or a machine? [21:03] s/user/primary actor/ [21:03] Human. At least that is the kind of user I care about. [21:04] hmm - but then this is a normal human to browser use case? [21:05] algermissen: yes. it's the client connector we talk about, I suppose. Not a generic browser but a javascript application which is used by the user and which talks to a server. [21:05] ok, will try anyhow - it is just harder to see what I mean then, I guess. [21:06] so there is actor and use case [21:06]