| Author |
REST and loose coupling
|
Peer Reynders
Bartender
Joined: Aug 19, 2005
Posts: 2906
|
|
RESTful web services are said to be inherently loosely coupled because of the generic nature of the GET, PUT, POST, DELETE interface. What are some of the ways that could inadvertently undermine that loose coupling? By having addressable resources that are too finely grained? By sharing a resource name generation algorithm with the clients or having too many public resource names (rather that revealing most resource names within the representation of the fewest possible number of public resource names)?
|
"Don't succumb to the false authority of a tool or model. There is no substitute for thinking."
Andy Hunt, Pragmatic Thinking & Learning: Refactor Your Wetware p.41
|
 |
Sam Ruby
author
Greenhorn
Joined: Jul 23, 2003
Posts: 13
|
|
inadvertently, eh? In general, too many URIs is less of a problem than not enough. If you have URIs where POST can mean one of several distinct things, based on the content passed, then the coupling isn't particularly loose. SOAP, as it is typically is used, does this. URIs constructed based on out-of-band information is also an example of tighter coupling. WSDL, and potentially WADL are examples of this. I've also seen systems where session state is achieved via a technique called "url rewriting". Sessions are an example of shared state, and tighter coupling. The problem here is that, in general, one can't take a look at a singe URI, or even a single request and determine if a system conforms to the constraints of REST. If one tries hard enough, one can always produce a tightly coupled system. More common inadvertent mistakes include using GET for non-readonly requests, and overloading POST, particularly using POST unnecessarily for read-only requests.
|
Sam Ruby
|
 |
 |
|
|
subject: REST and loose coupling
|
|
|