• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

REST and loose coupling

 
Peer Reynders
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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)?
 
Sam Ruby
author
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic