10.2 Build Serverless APIs with Functions

AI-200 expects you to build serverless APIs — typically HTTP-triggered Azure Functions that sit in front of Azure AI services. The Function App becomes your API host: no IIS servers to patch, automatic scaling with demand, and pay-per-execution on the Consumption plan (or reserved capacity on Premium when you need lower latency).

Anatomy of an HTTP-triggered AI API

An HTTP function exposes a URL such as:

https://<function-app>.azurewebsites.net/api/<function-name>

You can customize the route with a route template (for example api/chat/{sessionId}) so paths look like a conventional REST API. Clients send Content-Type: application/json bodies with prompts, parameters, or document references. Your function validates input, calls Azure OpenAI / Language / Vision / Speech (or your own model endpoint), and returns JSON.

Designing the request and response

Keep the HTTP contract boring and predictable:

• Request: messages, deploymentName or model id, optional maxTokens, grounding document ids.
• Response: content or choices, usage tokens if available, requestId for support/debug.
• Errors: 400 for bad input, 401/403 for auth failures, 429 when throttled, 500 for unexpected failures. Avoid returning stack traces to clients.

On the exam, prefer answers that validate input before calling paid AI services — garbage prompts still consume quota.

Sync HTTP vs async patterns

Model latency and cold starts make architecture choices exam-relevant.

Why async matters for AI backends

Consumption plan functions face execution time limits and can suffer cold starts. A single HTTP call that waits minutes for document intelligence + LLM summarization risks timeouts and poor UX. The standard fix:

1. HTTP function authenticates, validates, stores job metadata (Cosmos DB/Table), enqueues a message, returns 202 Accepted with a status URL or job id.
2. Queue- or Service Bus-triggered function performs the heavy AI work and updates job status.
3. Client polls a GET status function or receives a webhook/SignalR notification.

This split keeps the API responsive and lets workers scale independently when many documents arrive at once.

Composing triggers into an API surface

A production-minded AI back end is rarely one function:

HTTP functions form the API; other triggers form the workers. Bindings can load blob content into RunAnalysis or write outputs to Cosmos DB without large SDK blocks for simple I/O.

Authentication and exposure patterns

Function keys (function auth level) protect against anonymous internet abuse but are shared secrets — fine for server-to-server calls, weak for end-user identity. Common exam-aligned options:

• Function key in x-functions-key for internal tools and demos.
• Azure API Management in front of Functions for throttling, subscription keys, policies, and OpenAPI.
• Easy Auth / App Service Authentication with Microsoft Entra ID for user sign-in.
• Managed identity outbound from the function to Key Vault, Storage, and Azure OpenAI — never embed API keys in code.

When the question is about calling Azure OpenAI from a Function, look for managed identity or Key Vault references in app settings, not hard-coded keys in source control.

Proxying and CORS for browser clients

Browser-based AI UIs need CORS configured on the Function App if the SPA origin differs from the API host. Alternatively, put API Management or a static web app’s linked API in front. Do not disable auth to “fix CORS” — solve origins properly and keep keys off the client when possible (use a backend-for-frontend pattern).

Observability for serverless AI APIs

Wire Application Insights to the Function App. For AI APIs, log:

• Correlation/operation ids across HTTP → queue → worker.
• Model deployment name and latency (without logging raw secrets or full PII prompts in production).
• Dependency failures to Azure OpenAI (throttling 429s).

Exam angle: Application Insights integrates with Functions for distributed tracing; it is the default monitoring answer unless the question specifies something else.

Idempotency and retries

Queue-triggered AI workers may receive the same message more than once (at-least-once delivery). Design jobs to be idempotent: use a job id as the Cosmos document id so retries overwrite the same result instead of duplicating charges. Use poison-message / dead-letter handling (especially with Service Bus) when a document always fails validation.

Choosing HTTP routes that read well on the exam

Good REST-ish shapes for AI backends:

• POST /api/chat/completions — create a completion.
• POST /api/jobs — start async work; returns job id.
• GET /api/jobs/{id} — status and result.
• POST /api/embeddings — vectorize text for RAG.

Avoid stuffing multi-megabyte files into JSON when Blob Storage + Event Grid is more appropriate; pass a blob URL or SAS (preferably short-lived) or rely on managed identity server-side access.

Key Takeaways

• HTTP-triggered Functions are the core serverless API pattern for AI backends.
• Configure methods, routes, and auth levels deliberately; validate before calling models.
• Use sync HTTP for short calls; use queues/Durable/Event Grid for long AI pipelines.
• Protect endpoints with keys, APIM, or Entra ID; use managed identity for outbound Azure AI calls.
• Monitor with Application Insights and design queue workers for idempotent retries.