Optimizing API Gateway Strategy: Navigating Action-Based Pricing and Endpoint Design
As businesses scale their digital infrastructure, selecting the right API gateway becomes a critical decision—especially when pricing models influence architecture choices. Today, I want to share some insights and raise questions about how to balance cost considerations with clean, maintainable API design, particularly when dealing with action-based billing structures.
Understanding the Challenge
Imagine you’re evaluating various API gateway providers, and one vendor highlights their pricing model: charges are calculated based on the number of “actions” or “endpoints” your API exposes. This raises an important architectural question—should you consolidate multiple specific actions into fewer, more generalized endpoints?
In our current implementation, we’ve adopted a controller-based structure, for example, WidgetsController, with distinct actions like CreateWidget, GetWidgets, UpdateWidget, and DeleteWidget. Additionally, we sometimes create specialized actions tailored to particular use cases, such as GetWidgetsForUserTypeA and GetWidgetsForUserB. These specialized actions often serve as clear, dedicated pathways aligned with specific business logic.
Our backend is built with maintainability in mind: shared logic resides in service layers, while controllers primarily handle request routing. The use-case-specific actions exist mostly for clarity rather than code duplication.
Vendor Feedback and Concerns
The vendor suggests reducing the total number of endpoints by consolidating related actions—using query parameters or flags to differentiate behavior—arguing that this approach simplifies the API surface. They also promote their tooling for handling such internal logic at the gateway level, potentially reducing backend load.
However, from our perspective, this strategy seems driven more by pricing incentives than by genuine architectural improvements. Relying heavily on complex internal conditional logic within a single endpoint can make the API less intuitive and harder to maintain, especially as use cases evolve.
The Future of Our API
We’re also contemplating expanding our API with new actions and endpoints in the near future. These would return varied response structures based on the request, further complicating endpoint design. This prompts us to question whether consolidating actions could lead to convoluted internal logic or if a more granular approach would remain cleaner and more scalable.
The Core Question
Is there a tangible benefit—whether in performance, maintainability, or scalability—to merging multiple narrowly focused actions into a single, multifunctional endpoint? Or does maintaining discrete, purpose-specific endpoints often result in clearer, more manageable API design—despite potentially higher costs?
Call for Insights
I
