Why API Gateways Are Dead (2 of 2)
To help you understand a little why this is such a problem, you have to understand what an API is and what they are used for. Wikipedia has a fairly standard definition of :
An application programming interface (API) is a way for two or more computer programs to communicate with each other. It is a type of software interface, offering a service to other pieces of software.
This means that an API should be able to call another API in the same system.
How Do API Gateways Handle API Calls to other APIs
API Gateways don’t want you doing this at ALL! This is their Achilles heel. As you remember from the first part of this story, we talked about how API Gateways CANNOT handle ‘internal redirects’; thus an API call to another API call with an ‘internal redirect’ will always BYPASS the gateway.
So what they try to do is handle them with REDIRECTS and other tricks which require rerouting outside the API application and creating a new API call.
Below is a breakdown of frameworks and gateways and how they handle an API call to another API :
- redirect+middleman (slowest): this methodology allows your API manager to act like a ‘front controller’ (instead of the front controller in your API application) to reroute the call by adding a script for this API call and routing it to another. Impact: application drops a thread and does a round robin outside the DMZ to reconnect with the API Gateway, requires secondary duplicitous script for routing, request/response must be reissued. High latency. High I/O. Very slow. Vulnerable to MITM attacks.
- redirect (slow): this methodology redirects back to gateway for rerouting. Impact: application drops a thread and does a round robin outside the DMZ to reconnect with the API Gateway, request/response must be reissued. High latency. High I/O. Slow. Vulnerable to MITM attacks.
- internal redirect (fast) : this methodology uses prexisting client request/response within the api application to route the api call using the applications front controller. It reuses the existing token (for security) to access other api endpoints and existing threads. Impact: None. Very secure, fast, low latency. 100% internal to the application
Benefits of APIs Calling APIs
Calling an API (in the same system) from another API is EXTREMELY useful as it allows us to:
- avoid duplicitous code (KISS & DRY)
- avoid additionally calls from client (LOW LATENCY & I/O)
- reuse existing security components
- makes testing easier
This follows the rules of KISS and DRY and makes sure that documentation and API’s are fully compliant with each other.
Issues with APIs Calling APIs(???)
AWS lists some falsehoods that they believe to be issues (most of which ONLY apply to AWS Lambdas). I thought it would be good to go over them here:
- cost : ONLY if using like AWS Lambdas will it cost you per endpoint call. In your own API application on an EC2 instance, it is FREE.
- error handling : every endpoint can/should throw its own error separate of every other endpoint; thus this would ONLY be true with a bad API implementation. This is only true in Lambdas where they are tightly coupled (see next issue)
- tight coupling : API’s are NOT tightly coupled; AWS LAMBDAS are tightly coupled; Lambdas are ‘one endpoint per service’. Hence this is inherently false. Additionally, the process cannot be blamed for people coupling long processes with short ones. This would be like blaming SQL for people writing long queries.
- scaling: AWS claims all three processes must be equal in order to scale on Lambdas. This is false in normal API applications. In fact an API call to another API call can greatly reduce latency and overhead by reducing additional request/response from client.
In Closing
API’s should be able to reduce you coding and provide a universal way to call your backend… even from other API’s. By not securing this methodology, API Gateways create a loophole in your entire network that can be exploited at a moment notice.
And the solutions they do provide are extremely slow and vulnerable to MITM attacks. Gateway providers are aware of this vulnerability and will not disclose this but also cannot patch this.
Buyer beware.
