Whenever there is a transparent reverse proxy in from of an API, what is being created is a control point. This is also sometime described as an intercepting proxy, inline proxy or forced proxy
Why create an API control point?
Simpler Integrations
Pulling in any behavior that may normally live in the integration, into the control point eliminates that additional code and complexity.
Pulling in all the behavior that would be in the integration, except for the core logic eliminates all the code and complexity, except for the core business logic. Put another way, the integration is as simple as possible.
Simpler integrations are cheaper to implement, cheaper to maintain, easier to understand, and easier to fix.
Integration Cost Reduction
Pulling in any behavior that may normally live in the integration, into the control point eliminates the development and maintenance cost of that additional code.
Pulling in all the behavior that would be in the integration, except for the core logic eliminates all the development and maintenance cost, except for that of the core business logic. Put another way, the integration is as cost effective as possible.
Downtime Mitigation
Having a control point gives you the opportunity to respond when the upstream service is unresponsive or has known incorrect responses. That control point response may be as simple as a 504 Gateway Timeout, or it could include cached responses
The API may have availability or load issues, and you may want to provide centralized retry and/or queuing logic within the proxy. This eliminates the need for multiple implementations of retry and queuing logic on the client side. It also prevents a bad retry implementation from occurring.
No comments:
Post a Comment