+1 to Tim Ewald’s point that the ROA crowd might be pressing too hard to make PUT do some uncomfortable things. -1 (with all due respect) to Stefan Tilkov’s assertion that “anytime you find yourself adding words like “operation” to your representation, you’ve violated one of the core RESTful HTTP principles, which is that the intent should be communicated using the HTTP verb.” IMO, that’s an unfair litmus test for ROAishness.
Stefan was chiding a specific situation with respect to GData, which I do not know much about. But I do know that situations exist where I want to convey multiple “intentions” in a single physical call. You should be able to update a customer and a supplier in the same message -- to support arbitrary composition of the intent. What's the URI for that? That’s a rhetorical question, because a POSTing location and a schema indicating the message format are all you need.
I’m a big fan of ROA, but I’m worried that ROA fundamentalism will create a quagmire (shared by SOA) where all advice seems to be about what *not* to do. ROA makes it easy to bind the HTTP verb with your intent, but it doesn’t require you to do so. If I define a format for a message that can contain multiple “intentions” and then expose POST endpoint for processing messages, have I broken some Law of ROA? I don’t think so.
Or, like Tim asks, does ROA mean I have to PUT things in an imaginary basket and then PUT an imaginary thing into an imaginary place to make the basket get processed? No. There is no crime in using The Uniform Interface in a way that partners the payload, verb, and URI to dispatching logic or help give you a cleaner programming model.
Sure, it’s best to keep business process protocol stuff out of the data in your payload, which is what I think Stefan was really alluding to. That obviously gives you the ability to reuse a message format by isolating intention to the URI. But resources often have internal processes, like special state transitions, which may need to be manipulated via flags in the payload.
The free market rightly determined that WS-* is often too difficult to use and it probably doesn’t solve the problems you think it will. But if ROA forces people to use more effort or do unnatural acts to get a day’s work done, ROA will be out on its ass as well. In both cases, the good goes down with the bad.
Subscribe to:
Post Comments (Atom)
2 comments:
This is just an observation that is (a) not that useful or (b) much different to what you said, but you didn't have any comments and I was making a cup of tea.
'Services', by their generic/woolly nature don't offer any advice on how they should work or be designed, they are just a slower version of objects ;-). Service orientation is largely just a technology helper/tooling for some cross-cutting concerns (transport, description for proxies, security, policy (maybe). The extra bits are aspects that offer no advice on how to model or design the Service in particular.
Resources or ROA conversely offers a bunch of constraints that conflates a bunch of ideas that include uniformity of interface, a Model style and state transition via package hypermedia. A heady mix.
You can pick at the ROA buffet but it starts to lose it's overall appeal unless you bend to the Model and they way it wants to represent state. If you try to model processes rather than state to an existing model then you bump into a bunch of domain model/resources model impedance.
Put another way, ICalc could have been a Service in SOA and sold with a straight face, but for a REST approach you need to follow a whole bunch of rules/constraints to get the most goodness.
In summary, sometimes it is hard to take your existing OO Domain Model and match it up with pure resources and transitions.
I think of it akin to things like TDD changing how you design your objects, or MVC altering your site design. ROA, or REST in general is an 'intrusive' method, but generally worth it. It's a layered approach that leaks (in a good way) up and down.
Which is what you said, so I'm done. :-)
"...sometimes it is hard to take your existing OO Domain Model and match it up with pure resources and transitions."
True, but I can't image ROA will screw your OO model up any more than 30 minutes with a UML toolkit ;).
Post a Comment