REST trade-offs

2009-10-03 @ 22:19#

Fielding's Chapter 5 describes the REST architectural style. there's quite a bit of information in this one chapter of his 160+ page dissertation. currently, the part that interests me is 5.1 - Deriving REST. in it, he identifies six primary constraints, the roles they play in the REST style, and the trade-offs involved with each.

Client-Server
  • Provides: Separation of Concerns
  • Trade-Offs: None identified
Stateless
  • Provides: Visibility, Reliability, and Scalability
  • Trade-Offs: Potential decrease in network performance
Cache
  • Provides: Reduced latency
  • Trade-Offs: Can decrease reliability due to stale data
Uniform Interface
  • Provides: A simplified architecture
  • Trade-Offs: Degrades network efficiency
Layered System
  • Provides: Limits overall system complexity
  • Trade-Offs: Added overhead, potential increased latency
Code-On-Demand
  • Provides: Improved extensibility
  • Trade-Offs: Reduced visibliity

so, what's the big deal?

when you're fully aware of both the advantages and the disadvantages embodied in each of the primary REST constraints, you have a better chance of making good decisions on how to successfully implement large-scale distributed applications.

more to the point, when i hear and read conversations about REST, i don't see much evidence that people are contemplating the trade-offs; the choices that must be made when building real-life distributed applications. smart large-scale network applications fine tune these advantages and trade-offs. brilliant ones allow developers to continue to make choices during the life of the application itself.

this is not easy work. it is not for the simple-minded. and the process of weighing these competing interests is never complete.

code