REST trade-offs
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.