This is Duncan-cragg's Typepad Profile.
Join Typepad and start following Duncan-cragg's activity
Join Now!
Already a member? Sign In
Recent Activity
Next, I think you're saying "what if you want to add the ability to pay for several orders at once?" Your resource and interaction model has a layer of indirection via a link-rel to which we must POST the payment. This can be set to the order itself, but can be set later on to a "payment processor resource", to add multiple order payment functionality, without breaking single-order paying clients. (I don't know if you can GET your payment processor resource?) On the other hand, my Payment POST was defined/documented as being sent directly to the Order (Ticket). Clearly, a link-rel to a (GET-able!) resource that handles payments could be built in to my resource interaction model instead. This link could even be added only when payment was possible. But that would be nothing to do with satisfying REST and the Hypermedia Constraint; just a feature specific to this domain, to this resource and interaction model. And you don't need a link just for every POST you may want to do! That would be building in too much indirection "just in case". Instead, look at your domain or resource model for GET-able links to real domain resources. My Orders (Tickets) have links to their "Dealer" object - which creates Tickets and holds lists of them. I could simply say I now allow multiple payments to be sent to that Dealer.
Toggle Commented Dec 19, 2011 on Action URIs at dretblog
Well I think we're in violent agreement about a lot of this..! I think we both agree that the payment POST body should be self-descriptive rather than depending on round-tripping information in an opaque, server-only payment link. In other words, the body representation needs two important elements: (1) an indication that this is a Payment, and (2) a link to the Order to which it applies. This eliminates the significance of the "/order/42" and "payment" information encoded by the server inside your "" example, allowing us the freedom to POST the same body to resources other than per-resource, non-GET-able ones: such as the order itself, or a resource for processing payments. It also allows us to inspect and understand the message body, without needing to dig into the server's link, etc. You may consider whether this means the Payment is also declarative and - horror! it's a POST! - idempotent ... ! :-)
Toggle Commented Dec 19, 2011 on Action URIs at dretblog
> you say "you know when you can pay because of the > state of the Ticket, no link-rel necessary (it would > always point to the Ticket anyway!)", but i don't > quite get that. how do you represent the state and > detect the fact that it's ready to accept payment? Well, following the logic of this in steps: take out the redundant href, giving you [link rel="payment" /], which appears when it's possible to pay. Converting to a JSON representation, that could be { .. "payment": true .. }, or { .. "status": "payable" .. }. Just something about the state that indicates payability - in fact, it needn't even be overtly explicit like this. > isn't one of the fundamental principles of REST that > such a state change should be driven by hypermedia > controls, and thus a state change would be exposed > as a link a client can follow? that was my assumption, > but it seems that you have something else in mind. > how do you represent the state change in the resource? Well that's the crux of the difference in thinking between my view of REST when applied outside of the normal document/browser Web, and that of the "link-rel-action" advocates! I go into excruciating detail on this subject in my description of FOREST, but I'll try to distill it a bit for this discussion... :-) First, we've got to disentangle the two state systems: the resource or server state and the application or client state. Because POST isn't affected by the Hypermedia Constraint. The Hypermedia Constraint describes the way that the state of a client is supposed to be constrained and guided by hyperlinks in the state of the server. This constraint thus applies to the GET side of REST. Indeed, links that you can jump, and GET, and cacheing, are the bulk of the subject matter of REST. If it's a GET, the /client state/ changes. If it's a POST, the /server state/ changes! You can usually then see the effects of your POST in the stuff you then GET: for example, if you were redirected to a resource after the POST. So that makes it look like the POST drove the client application state, but it didn't. That's still GET-side stuff. So with this model, it doesn't make sense to manifest POSTability with a link that you POST to. Links are only for GET, for describing the hypermedia/hyperdata graph, for moving on /client/ application state. To move /server/ resource state on, you POST to the resource - the GET-able resource! - that you're interacting with, that the documentation says would be interested. Like you said, this means moving the 'verb' - or the 'intent' or the 'declaration of interesting client application state that may affect the server resource state' - into the POSTed content. You document that, when you see a server resource in 'this' state, it means you're good to POST your 'interesting client state' or 'action' (ugh) to it - and watch it change accordingly. This is a fundamentally declarative model, into which actions and verbs and imperative interactions have to be contrived. REST is fundamentally declarative, is my claim. That's my own re-interpretation of REST for machine-to-machine scenarios. Scenarios for which REST was not originally created, of course..
Toggle Commented Dec 11, 2011 on Action URIs at dretblog
I personally believe that this pattern, that I call 'link-rel-action', is really just RPC - the verbiness of the URL gives that away! Plus I also agree with Stefan, that a good rule of thumb is to ask what you can GET from such URLs. There's a wonderful chapter in that excellent book .. what's it called? Ah yes, "REST: From Research to Practice" .. there's a chapter in there about a REST pattern or model called "FOREST"*, which itself talks about orders and payments and so on.. :-) In FOREST, the author, Duncan Cragg, suggests POSTing Payment objects directly to their corresponding Ticket objects, where a Ticket is a server-side representation of a client's submitted Order. Like those slips you get in restaurants. Further, you know when you can pay because of the state of the Ticket, no link-rel necessary (it would always point to the Ticket anyway!) In fact, he also suggests a more peer-to-peer approach, POSTing updates on these Orders to these Tickets - containing new links to Payments hosted 'client side', which a Ticket object can GET from the client at its leisure. Cheers! * Duncan
Toggle Commented Dec 8, 2011 on Action URIs at dretblog
It's OK - I fixed the Wikipedia entry for 'Hyperdata' a few months ago, so that we can all use that instead... =0)
Toggle Commented Nov 21, 2009 on The Linked Data™ Police at dretblog
Duncan-cragg is now following The Typepad Team
Nov 21, 2009