This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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)?
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.