Two days ago, the API Gateway service on Oracle Cloud Infrastructure went live – read the announcement. This is a crucial component for many applications and in many solution designs. This new API Gateway is a prime candidate for example for inclusion in our reference architecture for OCI based solution designs. The API Gateway acts as a reverse proxy that handles HTTP requests from clients – either within OCI or on the public internet – and routes them to the configured endpoint. These endpoints can be any HTTP endpoint within OCI – such as Integration (OIC), an ingress on Kubernetes (OKE), a service in a Compute VM, ORDS on top of Autonomous Database – or outside of OCI. API Gateway also exposes Serverless Functions (Project Fn based) on OCI. One of the backend types supported by API Gateway – next to HTTP backend and Oracle Function as a backend – is Stock [response]; this type of backend always returns the exact same static response – headers and body. It can be used to quickly test [the health and availability and accessibility of) an API Gateway and a route (request policies are enforced in this case too) or to provide a mock response in stead of a backend that is still under development.
API Gateway lives in an OCI compartment, is associated with an OCI VCN and a public or private subnet. In case of the latter, the API Gateway is not publicly exposed and is used only for traffic within OCI.
API Gateway can perform request authentication, authorization and validation through an Authorizer function – an OCI Function that takes request headers and parameters and performs authentication for example through interaction with OAuth providers including Oracle IDCS.
Rate limiting is provided – we can define the max number of requests per second to any route – calculated per individual client ip or in total. This is used to not flood the backend, prevent DoS attacks, constrain cloud costs of back end resources
API Gateway provides CORS support in the APIs you deploy. When you enable CORS support in an API deployment, HTTP pre-flight requests and actual requests to the API deployment return one or more CORS response headers to the client. This means that APIs can be invoked directly from web clients.
API Gateway provides monitoring insight – overviews of the numbers of requests handled, response times taken and number of faults that occurred. Alerts can be associated with the metrics that are monitored. Additionally, details for each call can be logged – currently to log files on OCI Object Storage and soon to the new OCI Logging Service.
Costs associated with API Gateway
API Gateway is a light weight component – adding little overhead to calls – that scales very well. It is prices in a simple way: 1M API calls/month for $3. You do not pay per API Gateway or deployment – simply per call. And not much at that per call. With this level of pricing, the need for a VM with an open source API Gateway (because the API Platform solution was just to expensive) just went out of the window.
There is no connection between API Gateway and the API Platform service. There is some overlap in functionality of course. The latter is a much richer platform, focused on the full API [development & publication] life cycle, whereas the API Gateway is simpler, lighter weight and cheaper and not necessarily interested in the functional intention of the routes it is supporting.
Resources
Documentation on API Gateway: https://docs.cloud.oracle.com/iaas/Content/APIGateway/Concepts/apigatewayoverview.htm
Tutorial: Oracle Cloud Infrastructure API Gateway – Set up, creation, and deployment
Tutorial/Blog: Creating Your First API Gateway In The Oracle Cloud
Oracle Cloud Native – Oracle Cloud Infrastructure API Gateway: https://www.oracle.com/cloud/cloud-native/api-gateway/
Blog The Cloud Native Approach to Extending your SaaS Applications with a good example of a scenario of using API Gateway and an explanation of how the Authorizer Function fits into the story
