The gateway needs a model of your backend
Part B left you with a provisioned gateway that knows nothing. Before it can throttle, authenticate, or route anything, it needs a model of the backend it is fronting: which operations exist, at which paths, with which verbs, expecting which inputs, returning which shapes. In APIM that model is an API — a named collection of operations, where each operation is one verb at one path, exactly the GET /products/{id} shape 38a taught you to read. The gateway does not need to understand what a product is; it needs to know that this operation exists so it can attach policy to it, count it, and forward it.
This is the first place the front-desk metaphor gets concrete. The gateway publishes its own URL — campux-apim.azure-api.net/catalog/products — and internally maps each operation to the real backend address. From that moment the backend's true location is an internal detail no consumer ever learns, which is the property 38f and 38g turn into a security control. The API model is where that indirection is born: define the operation once at the gateway, and the real address lives only in configuration.
Import the spec; do not retype it
You can add operations by hand in the portal — name, verb, path, parameters, one at a time — and for a two-operation API that is fine. For anything real it is slow, error-prone, and immediately stale, because you are hand-copying a contract that already exists in machine-readable form. The professional path is to import. Point APIM at the OpenAPI specification from 38a and it builds the entire API — every operation, parameter, and response shape — in one step, and the generated documentation in the developer portal comes along for free.
| Source | When | Cost |
|---|---|---|
| OpenAPI import | You have a spec (you usually do) | Seconds; the whole contract, docs included |
| Azure resource | Fronting a Function App, App Service, or Logic App | Wizard reads the resource and wires the backend |
| WSDL / SOAP | A legacy SOAP service must be exposed | Imports and can even present it as REST |
| By hand | A tiny API, or a mock with no backend yet | Fine for two operations; a maintenance tax at twenty |
- OpenAPI import
- Building an APIM API from its OpenAPI document in one operation, so the gateway's model of the backend is generated from the same contract the backend already publishes — keeping the two in sync and turning "define the API" from an afternoon into a step in a pipeline.
Because the import is driven by a file, it belongs in your pipeline, not your mouse. The spec lives in the repository; the Class Twenty-Two workflow imports it into APIM on change; and the API model is now versioned, reviewed, and reproducible like everything else this bootcamp taught you to treat as code. Hand-clicking operations in the portal is the Class Twenty click-drift problem reborn one operation at a time.
The backend, made a first-class thing
Where does the gateway actually forward to? To a backend — and APIM lets you make that a named, reusable object rather than a raw URL scattered across operations. A named backend holds the base address and, importantly, the credentials or identity used to reach it (the managed identity of 38f, a certificate, a header). Point your API's operations at the named backend, and the day the real address changes — a new region, a blue-green swap, a move behind a private endpoint — you change it in one place and every operation follows.
This indirection is not bureaucracy; it is what lets the earlier promise hold. Consumers call the gateway's stable hostname forever, while behind the curtain the backend can move, scale, or hide without a single partner noticing — because they were never given the real address to begin with. Class Nineteen protected teammates from your changes with a branch; the backend abstraction protects consumers from your infrastructure with a name.
Mock responses — a contract before a kitchen
Here is the design move that surprises people. APIM can answer for a backend that does not exist yet. Attach a mock-response policy to an operation and the gateway returns a canned example — a 200 with a sample product — without forwarding anywhere. That sounds like a party trick and is actually a development pattern with real payoff: the moment the OpenAPI contract is agreed, the frontend team, the mobile team, and even partners can integrate against the mock while the real backend is still being built. The gateway owns the contract; the backend fulfils it later.
Play the timeline forward. Week one, the contract is signed and imported, mocked, and published. Weeks two through five, three teams build against a stable, documented API that returns realistic data, in parallel, with nobody blocked on the backend. Week six, the real backend lands, you swap the mock for the named backend on each operation, and — if everyone honoured the contract — nothing downstream changes. You have de-serialised work that used to happen in a frustrated sequence, and the thing that made it possible is that the contract, not the code, was the source of truth. This is the payoff of starting the whole track with what an API is: the contract is a deliverable in its own right.
The forgotten spec earns its keep
The half-forgotten OpenAPI file from 38a turns out to be the most valuable thing in the repository. Campux imports the catalog API into the Basic v2 gateway in one step: every operation, every parameter, the generated docs. What would have been an afternoon of retyping — and a second, drifting copy of the contract to maintain — is a line in the deploy pipeline instead. The gateway's model of the catalog is now generated from the same spec the backend publishes, so the two cannot silently diverge.
But the storefront backend was written for the website, and the partner-facing shape needs two fields the current version does not expose yet. Rather than block the partners, Campux publishes the agreed partner contract and mocks the two new fields at the gateway. The marketplaces start integrating on Monday against realistic data; the catalog team adds the real fields over the next fortnight; and when the backend catches up, the mock is swapped for the named backend operation by operation, with no change on the partner side. The email thread that offered a shared password is now a published, documented, mockable contract — and the partners were never blocked waiting for Campux's kitchen.
An API with shape, not yet behaviour
Step back and see what you have built across this part. The gateway now holds a model of the catalog — operations at paths, imported from the spec, pointing at a named backend (or a mock standing in for one), publishing a stable hostname that hides the real address. What it does not yet have is behaviour: no limits, no authentication, no caching, no header hygiene. Every request currently sails straight through. That is Part D's job. You have given the front desk a directory of who is behind which door; next you give it rules about who may knock, how often, and what it tidies on the way out.
Unblocking three teams with one mock
The mobile and web teams are idle because the new service's backend is not ready, and the old plan was to have them wait. You agree the OpenAPI contract in a morning, import it, mock realistic responses, and publish. Both teams start building that afternoon against a stable, documented API. Six weeks later the backend lands, you swap the mocks for the real forwarding, and nothing breaks because everyone built to the same contract. You did not write the backend faster — you removed it from the critical path, which is the more valuable trick.
Examination
Four drills, then two situations. The situations have no marking scheme — write your answer before you reveal the reasoning, or the exercise is worthless. Nothing is stored; this is between you and the page.
B — the real prize is synchronisation and reproducibility, not keystrokes. A hand-built API model is a second copy of the contract, and second copies drift: the backend adds a field, nobody updates the portal, and partners integrate against a lie. Importing from the spec means the gateway's model is derived from the same source of truth, and because the import is file-driven it belongs in the Class 22 pipeline — versioned, reviewed, reproducible. A is invented; runtime speed is identical. C is false; policies attach to any operation however created. D is false; hand-added operations do appear. The drift point is the one that matters: the most expensive bug in an integration is the gateway confidently describing an API the backend no longer serves.
B — a mock decouples the consumer's build from the backend's. The gateway returns realistic canned data for an agreed contract, so frontend, mobile, and partner teams start building on day one instead of waiting weeks for the kitchen. When the backend lands you swap the mock for real forwarding, and if everyone honoured the contract, nothing downstream changes. A misreads a development pattern as a permanent state — the mock is scaffolding, removed when the backend arrives. C and D invent behaviours mocks do not have: a mock is not a cache and generates no traffic of its own. The insight to keep: because the contract is the source of truth, work that used to be a frustrated sequence becomes parallel.
Hidden real address, a movable backend, and a stable public hostname. All three flow from the same indirection: consumers know only the gateway's URL, so everything behind it is free to change. The two rejects cross the line this whole track defends. The gateway does not understand your business rules — it models operations, not meaning, and pushing rules into it is 38d's cautionary tale. And the backend absolutely still needs its own authentication: defence in depth (Class 31) wants the backend suspicious even of the gateway, which is exactly why 38f closes it to the gateway's identity rather than trusting that traffic simply arrives. Fronting a backend hides it; it does not absolve it.
# onboard catalog API to APIM
1. Import the API from the OpenAPI spec in the repo,
via the Class 22 pipeline.
2. Point operations at a named backend so the real
address lives in one place.
3. Put the backend's real URL in the partner
integration guide too, as a fallback.
4. Mock the two new fields until the backend adds
them, so partners aren't blocked.
Line three — handing partners the real backend URL quietly demolishes everything lines one, two, and four build. The whole point of the API model, the named backend, and the stable gateway hostname is that consumers only ever know the front door, so the backend can move, scale, hide, and be protected. Publish the real URL "as a fallback" and partners will code against it, some will prefer it, and now the backend cannot move without breaking them and cannot be closed off without an argument — the gateway becomes optional, and a gateway you can bypass is a suggestion. This is 38f's Drill in embryo: a bypass with a friendly word ("fallback") attached. The distractors are the plan working: pipeline imports are correct (A), a named backend is exactly the one-place indirection you want (B), and mocking unbuilt fields to unblock partners is the §4 pattern, not dishonesty (D) — it is a documented, temporary contract the backend will fulfil.
Grant that hand-clicking feels faster in the moment, because it does. For the first import, twenty operations by mouse is a real hour and the spec import has a small setup cost. If the whole story ended today, your teammate would be right — so do not argue about today.
Then move the frame to the second day and every day after. The hand-built API is a second, hand-maintained copy of a contract that already exists in the repo. The next time the backend changes a parameter, someone has to remember to re-click it here — and the day they forget, the gateway describes an API the backend no longer serves, partners integrate against the lie, and the bug surfaces in production as a 400 nobody can explain. The spec import has no second day: it re-runs from the file in the pipeline, so the gateway's model is always derived from the same source of truth the backend publishes.
Close by making the good path the cheap path. Offer to wire the import into the Class 22 workflow once, so it is a line in a file forever after — less work than re-clicking twenty operations even once. The sentence that lands: hand-clicking saves an hour today and buys a drift bug every time the contract changes; the import costs an hour once and never again.
Reject the premise, because the choice is false. "Wait or fake" assumes the only real thing is the backend. It is not — the contract is real, and it can exist and be honoured before a line of backend code does. So the answer is neither: I agree the OpenAPI contract with the partner first, and treat it as a deliverable.
Then name the mechanism: mock at the gateway. I import the agreed contract into APIM and attach mock responses that return realistic data for each operation. The partner integrates against a stable, documented API immediately — not a fake in the pejorative sense, but a published contract the backend has committed to fulfil. Their two months of integration work now runs in parallel with our two months of backend work, instead of after it. When the backend lands, I swap each mock for real forwarding, and because both sides built to the same contract, the partner sees no change on cutover.
Close on why this is the senior answer. The junior instinct is to protect the partner from disappointment by either stalling them or improvising a throwaway. The senior move is to recognise that the contract is the asset, decouple the two builds through it, and take the backend off the critical path. The sentence that ends it: I don't make them wait and I don't fake it — I give them the real contract, mocked, so both sides build at once and cutover is invisible.
Five things worth carrying out of this part
- The gateway needs a model of the backend: an API is a named set of operations, each one verb at one path. The gateway models the shape, never the meaning.
- Import the OpenAPI spec; do not retype it. The import generates the whole API and its docs, keeps the gateway's model in sync with the backend's contract, and belongs in the pipeline as code.
- A named backend puts the real address (and its credentials) in one reusable place, so the backend can move, scale, or hide while consumers keep calling the gateway's stable hostname.
- Mock responses let consumers integrate against the agreed contract before the backend exists — parallelising work that used to be sequential, because the contract, not the code, is the source of truth.
- Never publish the real backend URL to consumers. The indirection the API model creates is the property 38f and 38g turn into a security control; a "fallback" URL throws it away.
- APIM imports more than OpenAPI: WSDL for SOAP services (with an option to surface them as REST), and direct wizards for Azure Function Apps, App Services, Logic Apps, and Container Apps that read the resource and wire the backend for you. The OpenAPI path is emphasised here because it is the most common and the one that keeps a hand-written REST contract in sync; the others follow the same "generate the model, don't type it" principle. ↩
- Mock responses are a policy, so they follow policy rules from 38d: they can be scoped to one operation and removed by editing the policy in the repo. A subtlety worth knowing: a mock returns a fixed example, so it will not exercise input-dependent logic — it is perfect for shape and integration wiring, and not a substitute for testing against the real backend once it exists. ↩