[00:00] timestamp, etc. [00:00] what is the reason to provide several states if the states are not significant? [00:00] attempts to replay the bookmark might results in 404 or a redirect to start again [00:00] I have a pattern that I use regularly call a "Sandbox" that is a subresource of some other resource. I allow the user to manipulate the resource and post it back to the sandbox. This allows the server to do preliminary validation and progressive disclosure on the resource. Nothing is stored to the backend database until the use actually does a PUT on the real resource. [00:01] algermissen: states might be significant, but not replay-able [00:01] I would definitely consider the returned entity "transient" as there is no permanent record of it on the server, but it does not have an identifying URL. [00:02] darrelmiller: that might be the same idea, but maybe we're not quite thinking along the same lines [00:03] I'm curious about your "a bit UI-centric" comment. I see REST interfaces as being all about UI content. [00:03] I think when people try and expose REST interfaces at any other layer, they run into all sorts of problems. [00:04] darrelmiller: i am also thinking of cases where i don't control the UI and the client might want to present things differently... [00:04] desktop app, console app, browser app, ajax-ified browser app - they all might choose diff UI [00:05] algermissen: you make a good point - not sure i answered sufficiently [00:05] I actually see all of those as different REST APIs [00:06] Take desktop versus mobile. You definitely do not want to try and display as much content on a desktop ui as mobile. So to mean you are showing a different resource. [00:06] oops. I mean the other way around. More on desktop, less on mobile. [00:07] yeah, diff workflows might require diff resources. this is another key point. [00:08] mamund: you mean that there are app states that 'go away', yes? [00:09] I think this relates back to Andrew Wahbe's point that the media type has everything to do with the client and not with the server. [00:09] never grasped what he means... [00:10] yes - app states that make sense in the moment (temporally), but will not make sense later [00:10] here's what got me started on this idea: http://code.google.com/p/implementing-rest/wiki/RESTfulSystem [00:11] mamund: I think it is a design issue! The wizard-style should be done this way: create a resource with POST (e.g. user account) then add to that resource with more request but 303 the cliet back to primary resource. [00:11] trying to dig up a post by roy where he describes that [00:11] mamund: Can you go further and say that transient states should only be visible to the one user? [00:11] algermissen: the link to that post is on the page there. [00:12] darrelmiller: yes, only to one user _and_ only at that particular time. same user later, would not be valid [00:13] algermissen: do you think each exposed state (URI) should be a valid start/stop place? [00:14] yes! [00:14] mamund: therefore, isn't the only way to get to one of those states to POST to some endpoint and the resulting entity NOT have a valid Content-Location URL [00:14] here is link: http://tech.groups.yahoo.com/group/rest-discuss/message/9805 [00:15] start reading below my favorite roy-ism: "Well, if you create a stupid design, it will do stupid things ..." [00:15] Think of it instead as a series of individual POST requests that are [00:15] building up a combined resource that will eventually be a savings [00:15] account when finished. Each of those requests can include parameters [00:15] that perform the same role as an ETag -- basically, identifying the [00:15] client's view of the current state of the resource. Then, when a [00:15] request is repeated or a state-change lost, the server would see [00:15] that in the next request and tell the client to refresh its view [00:15] of the form before continuing to the next step. [00:17] darrelmiller, mamund: I very much like the issue - it touches upon design principles (-> one should not do this and that because...) [00:18] algermisen: yes, this gets to the some nitty-gritty details, i think. good to hash this out and clear out assumptions, etc. [00:20] There is *a lot* behind the redirects that needs exploration. IOW, what is the HTTP-level meaning we can derive from the status codes, headers etc. ... and then hard code into clients (before even touching on the media type semantics) [00:20] algermissen: re: fielding's post here. do you think he means that each of the subsequent POSTs are valid (re)entry points? that they are each "steady-state"? [00:21] he means that the server allways redirects the client to the primary resource after some detail has been POSTed to it. that way, you only have a single application state: the account [00:21] I think he is talking about POSTing back to the same processing resource. The state is captured in what is returned. [00:21] bradley-holt (~chatzilla@65-183-135-35-dhcp.burlingtontelecom.net) left irc: Ping timeout: 245 seconds [00:21] yes, i agree with this notion that the server is the one to provide links to move things forward... [00:21] yeah, or what Algermissen said. That works too :-) [00:22] my focus recently is whether _every_ URI can be a steady-state. and that's why i'm baning on this transient state idea right now [00:23] I think (and I am really only guessing) that yes every URI is a steady state. [00:23] darrelmiller: see, and that's my stuggle. i think i have apps that can't fulfill this idea that all URIs are valid entry/exit points - that they can be replayed. [00:24] Even if a URI has expired and it returns 204 or even 404, is that not a steady state in itself. [00:24] ahhh.... [00:24] -> [00:24] POST /accounts/ [00:24] Name: Fred Meier [00:24] <- [00:24] 201 Created [00:24] Location: /acounts/4 [00:24] [00:24] Fred Meier [00:24] [00:24] [00:24] -> [00:24] POST /accounts/4/profession [00:24] "Teacher" [00:24] <- [00:24] there is only one app state: /accounts/4 [00:25] is app state representted by URI? [00:25] algermissen: I'm not sure what you mean by "only one app state" [00:25] ?? of course [00:25] well - app state is identified by URI [00:26] For me application state is "from the perspective of the client" . Each client has their own application state. [00:26] I have always understood that as resource state. [00:26] algermissen: i see your point. /accounts/4/profession is that a steady state? [00:26] No - client was redirected to another state [00:27] do there is a URI that does not represent steady state? [00:27] good point. [00:28] I like the analogy of driving in a car. The car is the client and the location, speed and direction of the car is its application state. The world around it is the resource state. To say a car's application state has a URI does not make any sense. Only the world around it can have an address (URI). [00:28] not sure i have a good point, but it's the puzzlement i experience right now [00:28] its about the distinction/rekationship between app state, resource and request uri [00:28] i think transient states are real, they exist and they are likely a part of all interactions (even in life, not computers) [00:29] uuhh - "transient state in life" [00:29] if I have a bottle of wine - am I then in a transient state?? [00:29] heheheh [00:30] my boubon bottle next to me here is about to transition to empty! [00:31] i am fully prepared to accept that my transient notion is just a side-effect of improper state representation design... [00:31] just not willing to give that up just yet [00:32] Som youd now like to have DELETE /wine/current --> See Other /Loc.: /wine/new HTTP-refill caopabilities [00:32] oohhhh - i like that idea [00:33] HTTP REFILL - new method! [00:33] anyway - it struc me a month ago or so that the notion of steady state is very central but often ignored. Your issues relates closely [00:33] hehe [00:33] Ok, you guys are making me think about drinking....must resist.... I know I cannot.... [00:33] hehehe [00:34] well, for jan, this is pretty late in the evening. [00:34] yes - but 2am is about my to-bed-time [00:35] you go all day, don't you? i don't have your stamina, i think. [00:36] well, I take many breaks - driving kids around and the like. [00:36] yeah - long days, tho. [00:38] so, i need to sort out my assertion about transient states. i'll work up a blog post this week and you guys can give it a careful review. [00:38] i appreciate the feedback. [00:38] Does anyone know if Roy or Mark Baker are planning to attend WS-REST? [00:38] not heard [00:39] i'll be there [00:39] Mark is a really nice guy. I got to meet him a couple of years ago. [00:41] mamund: Have you ever been to this type of academic conf before? Do know what the format of the workshop and tutorial will be like? [00:41] i have never been to WWW before. this is all new to me. not my crowd as i'm not an academic... [00:42] i;m looking forward to it, tho. new territory for me. [00:42] Me neither. Once I got out of university, I never looked back. [00:42] I just hope they have wifi :-) [00:42] i have two degrees, niether in computers. [00:42] hehee [00:42] yeah. if the hotels are weak, the venue should be fine [00:43] I hope so. The last two conferences I went to had no wifi. [00:43] yuk [00:44] ...and it is not like I could tether my phone either, it would cost me hundreds of dollars an hour. Canadian telcos suck. [00:44] i don't even have a tether for my US Sprint account. [00:46] mikekelly: are you still submitting a paper to the WS-REST track? [00:47] anyone else here going/submitting for WWW2010? [00:47] It was the linked-data workshop that I think Mike was talking about. [00:47] cool [00:49] hmm - seems like I am missing posts - can that be? [00:49] algermissen: "missing posts" you mean here in the room? [00:50] yes. all I see is you (mamund) [00:50] yeeesh [00:50] that's bac [00:50] bad [00:50] algermissen (algermiss@p54905732.dip.t-dialin.net) left #rest. [00:50] algermissen (~algermiss@p54905732.dip.t-dialin.net) joined #rest. [00:50] darrelmiller: you still there? [00:50] so - lets see what happens [00:51] k [00:52] well, no one it talking now! [00:52] ('cept me, of couse) [00:52] Anyway - did some PUT /glass -> 280 Enjoy and will take another 30min to think about your trans. states. [00:52] hehehe [00:53] you're a pip [00:53] mamund: Had to disappear for sec. I'm back. [00:53] np [00:53] algermissen is testing his session [00:53] GET /Beer [00:53] algermissen: you see darrelmiller posts now? [00:53] no... [00:54] crap [00:54] huh [00:54] ah - i can set individ. members to "Ignore" and that must have happened [00:54] ohhh [00:54] Back to steady state. [00:54] what client are you using [00:54] hehe [00:55] yeah - if you do stupid things you will get stupid results [00:55] Colloquy on Mac [00:55] channeling RTF again [00:55] ok [00:55] don't know it [00:55] maybe we can invite hime to the chat for two hours or so...hmm [00:56] sheesh, would be cool [00:56] i shell in [00:56] windoze at work, linux at home [00:56] ??? [00:56] shell in? [00:56] ah - via shell? [00:57] yeah. ssh into nullshells.net they let me run a screen session so i never really log off [00:57] keeps the CIA on their toes, too [00:57] :-) [00:59] w/ my library checkouts as well as my internet use, the US security folks must surely be keeping at close eye on me [01:01] mamund: I thought that was funny that you had done a post on JSON -> XML and I did one on XML-> JSON. I had not seen yours prior. [01:03] here is one Q to chew on: URIs identify resources, GET on resources puts client into steady state, steady state thus 'has' that URI. I can use that uri to go back to *that* state. [01:03] but state can change over time! [01:03] so what doe sthe uri refer to? the concept of some app state that can take several forms overtime? [01:04] darrelmiller: yeah, i thought you'd appreciate the irony. [01:04] when I GET uri I wantto get back into that state - but 'that state' does not mean 'that state at 8pm' [01:04] I see it as when you do a GET on a URI you retrieve resource state and it becomes part of the client's application state. [01:05] yes [01:05] at that point the resource state and the snapshot that is now part of the client's application state can diverge over time [01:06] see how again the temporal dimension is right there in REST at the core? [01:06] algermissen: resolution of the URI is definitely temporally dependent. [01:06] uris refer to some resources that exist to put client in some state [01:07] and it is inhernet and fine that that state can change over time [01:07] "resource is a time varying membership function that...|" [01:08] GET /current-time [01:09] I was working on a REST client the other day and I decided to make a distinction between two ways that I could use a URI. I could either Navigate To a URI in which case the current client state is completely replaced by the new representation, or I Aggregate a URI where I retrieve a representation that is added to my current application state. e.g. Images, stylesheets, [01:10] darrelmiller: navigate vs. embed links [01:10] Not sure if I am re-inventing terminology that already exists but it made things clearer for me. [01:11] Does any media type other than html make this distinction with links? Does atom? [01:11] IMO the principle is to split steady state in parts if the parts have different volatility [01:11] -> caching [01:11] algermissen: I think what you trying to say is it is all about caching :-) [01:11] oh - and if the parts are reusable [01:11] You were to fast for me [01:12] it's just resource identification and granularity [01:13] Has anyone tried applying the terminology of Domain Driven Design to resource identification. Eg, Aggregate roots, entities and value objects? [01:13] yes - it is a good fit [01:13] darrelmiller: DDD -> resources. interesting idea [01:13] hmmm. i know very little of the DDD space. [01:14] Currently I am trying to use the notions to help me design my URI space. [01:15] For me I like the question: "What is the significance of exposing resource X?" [01:15] IOW, start with no resources (== no possible communication, no app state) [01:15] then ask what is gained by adding which resource [01:16] IOW, how do you justify the exposure of a given resource? What is the client enabled to do by being able to see it [01:16] phew [01:16] hmm... [01:16] BTW, this is recorded, yes? Tons of god stuff in here today [01:17] akgermissen: state transition design. not URI, not resource, not even representation. [01:17] algermissen: Do you see resources as a point of interaction with the user , i.e. exposing a "use-case" or do you see it more from a domain model concept? [01:18] algermissen: http://rest.hackyhack.net/13Feb2010.html lags about five mins, but it [01:18] is all there [01:19] Well, service design is all about deciding which resources to provide and what representations to send. So, I like to ask stuff like this: [01:19] what if we have no resource (ideal because we have zero coupling) [01:20] the: which resource should I add? Why do I want to put a client in this or that app state? [01:20] i.e. is Login a valid resource? [01:20] The service design activity centers aropund the question into what app state you dissect your application [01:21] login -> HTTP auth [01:21] Where Login returns a form asking for credentiials. [01:21] nah - that is HTTP issue [01:21] IOW, can be handled without media type semantiocs [01:21] Ok, yes forgetting authentication issues. I'm just using it as a interaction entity [01:21] ah [01:22] Let me think of a better example.... [01:22] Brainstroming: what if you expose the complete app state (== all of the app) as a single resource? [01:23] altermissen: "...complete app state..." this is a key idea. [01:23] if the entire app state is small, why break it into units? [01:23] yes - why? [01:23] if the app state is large, where do the breaks occur? [01:24] yes, you are with me [01:24] reality is that apps have a very complex state (the app, mind you) [01:24] Ok. I could imagine a password minder where you retrieved your complete set of passwords in a single encrypted document. The client updates it and does a PUT. [01:24] so it makes sense to shield the client from details that are not pertient to the current interaction... [01:24] this is, IMO, the essence of app design for wide-area network apps. [01:25] yes -> communicating processes [01:25] keeping in mind that each interaction should be self-descriptive, self-contained, context-free... [01:25] issue is to achieve coordination (== a state where both processes know their state machines are aligned) [01:26] interaction design amounts to only sharing state details needed to complete a desired interaction - steady-state[1] -> steady-state[2] [01:26] updating a certain portion of the app data(!) on the server is a form of coordination (-> PUT passwords) [01:27] yes, "updating a certian portion of the app data" that's when it makes sense to not share the entire state graph w/ the client [01:28] but minimizing state circumference is not goal of rest - so how do we derive the desired granularity [01:28] ah - balance between number of messages and message size [01:29] chatty vs. large-grained. [01:29] by not confusing resource state with application state [01:29] ahhh [01:29] this also touches BPM [01:29] mikekelly: Shouldn't you be sleeping :) [01:29] by not requiring app state and resource state to match [01:29] hehehe [01:29] I should yeah [01:30] :-) [01:30] sorry [01:30] LOL [01:30] :D [01:30] mikekelly: see you in Raleigh in April? [01:30] potentially [01:30] very good [01:31] BPM -> the temporal aspects of the domain might require to do 'updates' in different steps (at different times) [01:31] geee - much stuff to untangle in this area. [01:32] well, i'm about outta gas here.... [01:32] i guess, I shuold go now - 8am is get-up time [01:32] hehehe [01:32] later, folks [01:32] bye! [01:33] and thanks - that was very valuable [01:33] peace-out! [01:33] Enjoyed by all, I'm sure. [01:33] tataa [01:33] Action: mamund closes up shop and heads out the door [01:40] hmm [01:40] ETags and server negotiation [01:41] if I have two representations at a URI served via server conneg [01:42] and ETag's against them [01:43] actually nvm I just answered this in my own head [01:43] I need to go to bed :) [01:44] that's interesting though - any server side conneg logic would need to be layered up on top of any ETag/validation logic [01:57] darrelmiller (~chatzilla@bas4-montreal45-1279574616.dsl.bell.ca) left irc: Quit: ChatZilla 0.9.86 [Firefox 3.6/20100115144158] [02:04] algermissen (~algermiss@p54905732.dip.t-dialin.net) left irc: Quit: RESTing [03:11] KevBurnsJr (~kevburnsj@c-67-161-65-81.hsd1.ca.comcast.net) left irc: [05:01] KevBurnsJr (KevBurnsJr@c-69-181-187-21.hsd1.ca.comcast.net) joined #rest. [05:09] POST /drinks 202 Accepted Location: /drinks/1 [05:51] prestonc (~prestonc@c-98-232-232-72.hsd1.or.comcast.net) joined #rest. [05:52] POST /drinks 202 Accepted Location: /drinks/2 [05:53] I've seen a lot of examples of RESTful implementations that deal with objects proper. Like User->get = User->list. [05:54] Is it normal to look at apis in terms of concepts. Like when I update a client calls my User API, for example, I'll also be dealing with related tables. [05:56] PUT /bulb {"mode":"on"} [05:58] I think you're asking whether every resource needs to be an object. [05:58] basically, yeah [05:59] I'm still wrapping my mind around how you'd actually structure things [05:59] GET /posts/latest is not necessarily a distinct object, but it is a resource [05:59] GET /mysite/users/4 makes complete sense to me [05:59] or GET /mysite/users/5/comments [06:00] I'm okay with all of that. However, what I'm not sure of is if I map those commands to individual objects (in this case PHP) or through a larger PHP service handler or controller that then delegates to other classes that would save the join tables, etc. [06:01] Are you familiar with MVC? [06:01] yep [06:04] Maybe you're waiting for me. So I have done MVC forever in Java. Struts, etc. I've heard that talked about as a way to handle REST, but I can't figure out what that would look like. What would the views be, exactly, the controllers, the models. [06:06] Here's an example application configuration http://uforcerec.hackyhack.net/recess/routes/ [06:06] I'm guessing the models would be the individual objects, User, Comment, etc. And I'm guessing they'd know how to load and save themselves. But after that I'm not sure what would be the view and what would be the controller. Right now for "controllers" I have objects like UserService that takes an HTTP request passed from the rest service handler and does a simple switch/case on what type of request it is and calls the object directly [06:06] right now. [06:06] HTTP Method - Url - Controller - Action [06:07] That's using Recess proper, though, right? [06:08] It's an application generated using a PHP application framework named Recess [06:08] I was thinking this would be simple enough to do by hand in case Recess was heavyweight or slower. [06:08] heavyweight yes, slower, not necessarily [06:09] but if you're going to do something by hand, i recommend building from scratch on top of an ORM like Doctrine [06:09] I've done that more than once [06:10] Here's the routes file for the last web application framework I created from scratch [06:10] That's not happening. The architect of this project wants to build for speed from the ground up. So he's thinking ADODB, really basic stuff. [06:10] http://pastie.org/822946 [06:10] So the view part, are those class calls? [06:11] in some cases views can be classes. Recess has a class called AbstractView which other Views extend [06:11] but that doesn't necessarily need to be the case [06:11] hmmmm [06:12] Yeah, I'm banging my head a bit trying to write this on my own. Not sure if that's lame, but I'm used to tidy frameworks to provide some structure. [06:12] in MVC frameworks I've created, I just Template::render($controller.'/'.$action.'.php'); [06:14] I used this router in my last framework [06:14] http://allseeing-i.com/Bare-bones-Rails-style-MVC-Request-Router-for-PHP [06:14] it worked well with only a few tweaks [06:14] so in that case you'd have a separate file called Users/view.php or something like that? [06:15] ya, absolutely. [06:15] you want to separate your controller logic from your display logic [06:15] that's objective numero uno. [06:16] of course. I just wasn't seeing how that would be done cleanly in PHP. [06:16] Being kind of a PHP neophyte [06:17] here [06:17] http://blog.kevburnsjr.com/simple-templating [06:19] the punchline is that somewhere in your controller you include a php file which gets evaluation and prints a bunch of html, then you steal the output and store it in a string, and then do whatever you want with it. [06:20] though you might have better luck with php-specific inquiries in ##php [06:22] Yeah. Part of the problem is that I was directed by someone else on this project to use Smarty and ADODB and nothing else. And so I'm hitting spots like this where I want to make logical sense of the controller and how to organize files, etc. [06:22] also: anyone who wants to write their own framework from scratch on ADODB for optimize for speed probably doesn't know what they're doing. [06:22] Don't disagree. This individual is very very concerned about scaling long term. [06:23] Problem is that it's a block for me to progress. [06:23] Since I'm a business/web programmer, not someone who typically writes the actually MVC or ORM layer myself. [06:24] so if you're me and you're ignoring him and trying to implement it as lightweight as possible, would you go with something like Recess or one of the examples you provided? [06:24] I would go with something well-known. [06:24] they probably won't like Cake cause it's a slug [06:25] Yeah, cake was being used earlier [06:25] Zend is always a popular one [06:25] Zend isn't going to happen. :) [06:25] Just knowing this guy. [06:25] I don't know, honestly, that I have to worry too much about the "true" MVC layer. [06:26] Symfony and CodeIgniter are two others i'd recommend. [06:26] Tell your guy to look at Doctrine. [06:26] Symfony works very well with doctrine [06:26] and it's very well documented. [06:26] http://www.symfony-project.org/ [06:26] His idea is of ajax calls to web services. [06:26] Thus my focus on nailing down the web service layer [06:28] http://www.symfony-project.org/jobeet/1_2/Propel/en/16 [06:29] Symfony Performance : http://www.symfony-project.org/book/1_2/18-Performance [06:31] Hmmm. So this is end to end. MVC, web services, ORM layer. [06:58] prestonc (~prestonc@c-98-232-232-72.hsd1.or.comcast.net) left irc: Read error: Connection reset by peer [06:59] prestonc (~prestonc@c-98-232-232-72.hsd1.or.comcast.net) joined #rest. [07:10] prestonc (~prestonc@c-98-232-232-72.hsd1.or.comcast.net) left irc: Quit: Leaving [07:37] KevBurnsJr (KevBurnsJr@c-69-181-187-21.hsd1.ca.comcast.net) left irc: [07:55] algermissen (~algermiss@p54906877.dip.t-dialin.net) joined #rest. [07:57] Can we make the bot put anchors in the transcript for linking to individual posts? [10:06] ahe (~ahe@dslb-088-065-009-018.pools.arcor-ip.net) joined #rest. [11:08] MrMojoRisin (~kane@116.68.73.48) left irc: Ping timeout: 246 seconds [11:09] MrMojoRisin (~kane@116.68.73.48) joined #rest. [13:29] would y'all agree that... [13:29] services implement business functions [13:30] business functions implicitly define a set of client goals (e.g. place order, update account) [13:30] and thus that a service's design essentially needs to enable the desired goals? [15:38] ------ [15:39] what criteria must be true for a steady state? IOW, what must be taken care of when we send a client into the next steady state? [15:40] Me thinks: A steady state must be have semantics that are independent from the request that lead to it [15:41] otherwise I would need knowledge about the request that lead to the state to understand it. (But steady states must be understandable 'in isolation' [15:42] this implies some serious stuff reagrding how you design responses etc. (see yesterday's wizard vs. building-the-account approaches) [15:51] bradley-holt (~chatzilla@65-183-135-35-dhcp.burlingtontelecom.net) joined #rest. [15:56] bradley-holt (~chatzilla@65-183-135-35-dhcp.burlingtontelecom.net) left irc: Ping timeout: 245 seconds [15:58] bradley-holt (~chatzilla@65-183-135-35-dhcp.burlingtontelecom.net) joined #rest. [17:59] MrMojoRisin (~kane@116.68.73.48) left irc: Ping timeout: 256 seconds [18:06] algermissen: following up on your earlier lines regarding steady-state... [18:06] MrMojoRisin (~kane@116.68.73.48) joined #rest. [18:07] right now, i think SS (steady-state) is one that can be a start or end point. [18:07] thus any state that is not a valid start/end is a transient one. [18:07] transients are fine, they just need to handle attempts at start/stop. [18:08] if user activates a transient state URI, server should 4xx or 3xx as server sees fit to do. [18:09] if user stops in the middle of some transient state the server must take care to not leave app state in a bad way. [18:09] that, i think is the sum of the issue regarding SS and TS. [18:10] the next issue then, is to locate/identify SS/TS in your HTTP app flows and code accordingly.. [18:10] does my server handle attempts to activate TS URIs properly? does it handle stops @ TS properly? [18:11] finally, i think the diff between TS/SS might be meaningless to client apps. they only know links. [18:30] KevBurnsJr (KevBurnsJr@c-69-181-187-21.hsd1.ca.comcast.net) joined #rest. [18:37] KevBurnsJr: thanks again for archiving the channel. already bookmarked the site. [18:39] np. I'm hacking away at it now. Hoping to put the log parser on GitHub so others can add to it. [18:40] very cool. [18:53] how does the server know whether a request forms the client's application state as transient? [18:53] all it sees is requests.. [18:54] to me, the server doesn't really have any direct 'knowledge' of application state further than the implementation having to support some hypermedia protocol (e.g. APP) in terms of the resources it exposes [18:55] but a request is just a request.. and a representation is a representation.. [18:55] the application state is constructed by the client according to the hypermedia protocol [19:04] mamund: Q why would you expose a transient state at all? [19:06] re: how does the server know whether a request forms the client's application state as transient? it can't (or maybethe media type can tell it, but I doubt so) [19:06] josemoreira (~jmoreira@a213-22-159-52.cpe.netcabo.pt) joined #rest. [19:06] IMHO, any exposed resource that is a primary resource (Web page, not image, css etc.) is a steady state resurce [19:07] if client goes from primary resource to priary resource then it allways advances the application [19:13] Action: mamund wanders back into the room [19:14] algermissen: consider the way oauth works (openid, oauth, not sure)... [19:14] there are a number of interactions that must complete before the next SS is reached. [19:14] the interim interactions are TS and are not valid start points. [19:15] often this is because there are temporally sensitive interactions going on... [19:15] ones that cannot be allowed to "replay" at some later time [19:16] consider an online, timed, adaptive skills test... [19:16] each Q is presented based on the answers to the previous Q... [19:16] but those transitions would all be taken automaticaly right? [19:17] each Q must be answered in a preset amount of time... [19:17] these are states that are not valid start points as some future moment in time. [19:17] algermissen: automatically? [19:17] you mean via redirects? [19:18] IMO, automatic is not a factor here. auto or not, there are transient states involved... [19:19] it's true that comon browsers might hid some of these transient state transitions from the human user... [19:19] that's fine. but they exist... [19:19] and some clients may not hide them or prevent replaying them at some future point (consider bots and other m2m interactions) [19:20] Action: mamund needs to GET /lunch. back shortly [19:52] Action: mamund is back from lunch [19:54] mikekelly: "how does the server know whether a client request... is transient?"... [19:54] server knows if the URI activated by the client is valid or not; knows if the current app state will allow server to fulfill client request... [19:55] consider a client which POSTS a "buy" request to a server that has no shopping cart aossicated w/ that buy request. [19:55] consider a server that gets a "GET /my-reserved-seats/" request of the client when the time period for accessing that seat reservation has passed. [19:57] to bring up something algermissen mentioned recently, _time_ is an important factor in all this... [19:58] some resources identified by a URI may become invalid at some future point. this is not a bug or error, this is reality and, in some cases, by design. [19:58] in these cases, that URI can be said to be transient, not permanent. [19:59] this is diff from a URI that is permanent, but the resource representation assoicated w/ that URI changes over time. [19:59] something like "/GET current-time" is such a case [20:00] some resources identified by a URI may become invalid at some future point: Note that the resource do not become invaid - they just happen to be temporraryly empty (404) or forever empty 410. [20:03] algermissen: hmmm... [20:04]