Here is a fact that changes how you see the whole platform: everything the cloud does is an API call. The web console is a website making API calls for you. The aws and az command-line tools are programs making the same calls. Terraform makes them. The SDK you will write Python against makes them. There is no secret second mechanism behind the buttons — learn the API and you stop being limited to what someone chose to put on a screen.

The anatomy of one call. A request is four things: a method (you already met these — GET, POST, PUT, DELETE), a URL that names the thing — the endpoint — some headers carrying who you are and what format you are speaking, and sometimes a body, usually JSON. The answer comes back as a status code and, usually, more JSON. On the command line that is one line:

curl -H "Authorization: Bearer $TOKEN" https://api.example.org/v1/patients/482

Read the status code before you read anything else. The families you already know — 2xx worked, 3xx go elsewhere, 4xx you got it wrong, 5xx they got it wrong — but four specific codes carry most of the debugging. 401 means I do not know who you are; 403 means I know exactly who you are and you may not do this. Confusing those two costs hours: the first is a broken credential, the second is a permissions policy. 429 means you are being rate-limited, and 409 means you are fighting someone else over the same record. A special warning: some APIs return 200 with an error message inside the body. Code that only checks the status code will sail straight past a failure.

Authentication, and the credential that should not exist. APIs identify callers with an API key, a bearer token, or — on AWS — a request signed with your credentials. The rules are simple and absolute: never in source code, never in a URL (URLs end up in logs), never in a chat message. Environment variables for local work, the platform's secret store or a role-based identity in production. The best credential is the one that does not exist because the machine's own identity is doing the asking — the same principle as the IAM module.

Rate limits, retries, and idempotency. When you get a 429, wait and try again — but wait longer each time, with a little randomness added, so that a thousand clients recovering together do not all knock at the same instant. That is exponential backoff with jitter, and it is a phrase worth saying out loud in an interview. Retrying safely depends on idempotency: doing the same call twice must leave the world the same as doing it once. GET, PUT and DELETE are naturally idempotent; POST is not, which is why serious APIs let you attach an idempotency key so a retried "create payment" does not create two payments.

Pagination — the bug you will write once. Ask a cloud API to list your resources and it will answer with the first page and a token for the next. A script that ignores the token sees fifty of your two hundred servers and reports success. Every time you write a listing script, ask yourself where the loop is.

Three shapes you should be able to name. REST is the default: addresses that name things, standard verbs, JSON. GraphQL gives one endpoint where the client asks for exactly the fields it wants — excellent when many different clients need different slices, harder to cache. gRPC is a compact binary protocol for service-to-service calls inside your own system: fast and strictly typed, not something a browser talks directly. And webhooks run the other way — you publish an endpoint and someone else calls you. If you accept webhooks, you must verify the signature on every one, or you have built an open door that anyone on the internet can push events through.

One practical exercise, right now, that costs nothing: run any cloud CLI command with --debug and read what it prints. You will see the actual HTTP request the tool built — method, URL, headers, body. That is the whole cloud, with the lid off.