I've just been engaged in an interesting twitter chat about REST and basket checkout:
colin_jack @serialseb ...but as resources in their own right.
colin_jack @serialseb Yeah, thats an approach I like. I'd make it work as RESTful in my head by not seeing things linked to as part of session state...
serialseb @colin_jack Well @adean probably has a different and wisest opinion. Mine is that the uri identifying a resource can be a represetnation...
colin_jack @serialseb Yeah, is it not RESTful? So your saying POST/PUT the basket with URLs of items (sorry, twitter makes discussions hard to follow). serialseb @colin_jack Thats where I argue that passing URIs around is not necessarily unrestful, depending on what you do with such uri
colin_jack @serialseb I guess I just can't see client PUTting all the infromation in those cases, guess I need to read dissertation...
serialseb @mamund But thats the point. /cv is a generic resource that can have conneg. /cv.doc is a resource that has only one represetnation ever.
mamund @serialseb it might make more sense if your resource URI was /cv instead of /cv.doc. the "doc" is a 'content-type'
serialseb @adean I'm looking at it from a webarch point of view. I don't say such distinction is not necessary, but that it doesnt seem to bring value serialseb @colin_jack It delves from the argument that state exist within the representations. And that the server shouldnt rely on client behavior.
adean @serialseb Maybe you don't, but Roy doesn't say the representations are different to resources except where there is only one media-type
colin_jack @adean I guess I'm just not seeing how posting the whole basket for checkout works, are there any blog entries that specifically cover this.
serialseb @adean I see no value in distinguishing the resource identified by /cv.doc that exist in one and only representation. A closed IR?
adean @serialseb He he ... It *does* if you want to call something RESTful :-) It's right there in the dissertation serialseb @adean differenciating the representation from the resource doesn't always make sense.
serialseb @adean you're quire right. As for representations, we need to not downplay the existence of representation-specific resources, for which...
adean @serialseb As I say, perfectly valid HTTP stuff, just not RESTful (this kind of discussion is why we need to do our two-headed presentation)
adean @colin_jack But what you are POSTing must be a representation of the basket to be purchsed - that's the key thing
serialseb @adean transfer would still happen. Unless the resource is local, in which case the server could shortcut the delivery of the representation adean @colin_jack You can post to checkout if you want the server to choose the resource identifier: the actual name of checkout is opaque to REST
serialseb @adean if the server expects a shopping cart representation, it'd request whatever format it understands and become itself a UA.
adean @serialseb However ... what content-type should the server ask for?? And it certainly doesn't transfer a representations, so not RESTful
adean @serialseb Yes, you could post a link to the data (assuming that it could be anywhere on the web) if the server supports that ...
colin_jack @adean @serialseb How about if you have a ShoppingBasket and you POST a CheckoutRequest or something to it, or is that awful?
serialseb @adean ... on the server? What if the client simply does a PUT with Content-Type: text/uri-list and content being the uri to the basket?
serialseb @adean agree if it is required for the server to know about the shopping cart to do a checkin. But what about leveraging hyperlink... colin_jack @adean Ahhh, yeah. Guess thats why Jim Webber/Ian Robinson and so on are calling their approach Web oriented.
adean @serialseb Because the 'personalised resource' is optional to clients: they can happily store the app state locally without failing checkout
adean @serialseb But if the client will PUT the whole basket to checkout (even if there is no 'personalised resource') then that's fine ...
adean @serialseb if the checkout requires the basket to be in session state (even if exposed as a resource), it's not RESTful ...
adean @serialseb let's say that the 'personalised resource' is a customer basket ... serialseb @colin_jack Well it's not about the tool, it's about the arch. The tool in question provides poor support for what is needed for the arch.
serialseb @adean ... state of such resource and the mean to interact with it is returned on GET /shoppingcart/2554? serialseb @adean Need to define what we cover by state. are you saying POST to /shoppingcart/2554 looses serendipity? Especially when the entire...
adean @serialseb Sorry Seb, have to disagree - if you do that, you lose serendipity of reuse if the server needs to session state to be present colin_jack @serialseb Yeah thats the solution I'd heard of, but if you do go for that then your still breaking the rules Neward talks about aren't you?
serialseb @colin_jack one solution is to expose the context as personalised urls, aka first-class resources. adean @colin_jack I agree with the statement. You can have a well-written Web application and use server session - you just can't call it RESTful
adean @CAMURPHY Heh, sorry, didn't know that! In that case, I'm definitely up to have it taped :-)
colin_jack @adean "cannot take advantage of any stored context on the server", just thinking of Amazon working that way... colin_jack @adean Already following your REST delicious "feed", he's definitely got a lot of good quotes. Here's a question, how far do you go with...
adean @colin_jack If you like Roy quotations, I have a bunch of them bookmarked :-) http://tinyurl.com/5w65lu colin_jack @adean Fielding definitely doesn't pull any punches! :)
colin_jack @adean Oh sorry yeah definitely. Still trying to get my head around idea of all state going in each request though...
adean @colin_jack The fallacy is REST == HTTP, the fact is REST IN {File, HTTP, FTP, Gopher, WAIS, URN, (waka)} http://tinyurl.com/5tbuvp colin_jack @adean Would love to hear the talk, which bit is the fallacy (e.g. what he's saying or the other side).
colin_jack @serialseb Speaking of which I've got to buy Restful WCF when its out! :)
adean @colin_jack Already bookmarked :-) I subscribe to Ted's blog & this is one of the Fallacies I will be talking about at DDD
serialseb @colin_jack Very good post indeed. Think Roy should've trademarked REST, would've made it easier. Unlearning Don Box's bs on REST will be...
colin_jack @iand New REST blog entry from Ted Neward that you may or may not be interested in: http://is.gd/6BAz
No comments:
Post a Comment