In previous episodes and through this series, I’ve challenged well-established notions about ReST. Now that you're drawn to ReST, hearing that it's not a silver bullet might surprise you. The intent of this series was never to pitch ReST but to inspire critical thinking. ReST is wonderful. ReST is simple. ReST is flexible. Yet, it remains one of the most misunderstood and misused styles. Using ReST to drive home a point just made sense.
Software design is a bit different from its traditional counterparts. Use cases are key to any software design, and I’m going to use a few of them to explain why ReST is not a silver bullet.
A Use Case
So, what is a use case really?
A use case is a specific situation or scenario in which a system, product, or service is used to achieve a goal. It describes an interaction between a user and the system, focusing on how the system fulfills a need or solves a problem.
What Are the Key Elements of a Use Case?
- User: The individual or entity interacting with the system.
- Goal: The intended outcome or purpose of the system.
- System: The tool enabling the execution of the use case.
- Context: The environment, circumstances, or conditions in which the use case occurs.
You’ll notice that context matters significantly and drives most of the design choices. Let’s explore a few examples to illustrate why ReST is not a silver bullet.
Real-Time Communication
-
Why?
ReST is strictly a request-reply design. Nothing happens unless a request is made. A ReST service cannot push notifications to its audience because it wasn’t designed for such applications.
Alternatives: You can use WebSockets or Server-Sent Events (SSE) to handle real-time communication.
Latency and Bandwidth-Sensitive Systems
-
Why?
ReST is stateless, making real-time communication verbose, as each request must be independent and therefore bulky. This isn’t bandwidth-friendly.
Alternatives: Use binary protocols like Protocol Buffers (protobuf) that are optimized for such scenarios. These protocols eliminate the need for headers, status codes, etc., making communication more efficient.
Inherited Non-ReST System
-
Why?
Sometimes, you inherit a non-ReST system and are unable to change it. This doesn’t mean you can’t improve it, but the scope might be limited to smaller features rather than a full overhaul.
Alternatives: Unfortunately, there might not be a viable alternative when you’re constrained by the system you’ve inherited. Overhauling may not be an option, so ReST might also be out of reach. However, this isn’t inherently a bad thing—it’s simply a matter of doing the job that needs to be done.
Conclusion
There are plenty of situations where ReST simply isn’t the right choice. That doesn’t mean everything we’ve discussed in this series is inapplicable. The key is to understand your use cases, determine what fits well, and then craft the interactions accordingly. The idea of viewing interactions as human-like conversations isn’t limited to request-reply styles like ReST. A similar thought process can be equally useful in event-driven architectures too.