A long-running permitting microservice already listens behind a load balancer on OKE. The team wants API Gateway to forward /v1/applications there. Which back-end choice is appropriate?
Select an answer to reveal the explanation.
Short Explanation
If the work already has an address, send the gateway there with an HTTP(S) URL back end. Do not wrap a healthy microservice in a do-nothing function just to look serverless.
Full Explanation
For a long-running permitting microservice that already listens behind a load balancer on OKE, API Gateway should use an HTTP or HTTPS URL back end pointing at that existing service. Configure timeout and SSL verification options as required so /v1/applications forwards to the live microservice without rewriting a healthy architecture into artificial serverless wrappers.
Wrapping the service in a no-op Oracle Function solely so the back end can be type Functions adds latency, failure modes, and cost for no functional gain. A stock-response back end returning 501 for every live request is only a placeholder, not production forwarding. Claiming only Connector Hub can target an HTTP URL from API Gateway is false—HTTP and HTTPS URL back ends are native gateway capabilities for existing services.
Exam caveat: align gateway route timeouts with the microservice’s realistic latency, especially for permitting workflows that run longer than typical function invokes. Operational check: set the route’s HTTP or HTTPS back end to the load balancer URL, verify TLS validation settings match the upstream certificate, send a test /v1/applications request through the gateway, confirm the OKE service handles it end-to-end, and monitor for timeout mismatches between gateway and upstream.