APIs & Protocols
An analyst rarely writes code but constantly writes contracts — how two systems will exchange data over HTTP. So the contract does not fall apart in production, you must know exactly what a request and response are made of, what a status-code class means, which method is safe to repeat, and which one creates a duplicate.
This topic collects the fundamentals every API spec rests on. The traps, named up front: REST is confused with a protocol, POST is called idempotent, XSD is said to describe JSON, and the 4xx class is swapped with 5xx. Each is a classic interview failure. The full map is in the layers below.
Topic map
- HTTP protocol — what a request and response consist of and the meaning of the five status-code classes.
- HTTP verbs — how
GET,POST,PUT,PATCHdiffer on the read/write and idempotency axes. - Idempotency — why a retry creates duplicates and how an idempotency key stops them.
- REST principles — REST as an architectural style over HTTP and its constraints.
- API styles — comparing
SOAP,REST,gRPC, andGraphQLand where each fits. - Data formats —
JSON,YAML,XMLand their schemas (XSD,json-schema,WSDL).
Common traps
| Mistake | Consequence |
|---|---|
Swapping 4xx (client) and 5xx (server) | Wrong conclusion about which side to fix |
Calling POST idempotent | A retry after a timeout creates duplicate orders |
Calling REST a protocol like SOAP | You expect an enforced standard REST does not have |
| Attributing protobuf and HTTP/2 streaming to REST | Confusion: these are gRPC properties, not REST |
Thinking XSD describes JSON | XSD defines XML structure; JSON is described by json-schema |
| Trusting the client and not validating on the server | Duplicates and malformed data slip into the system |
Interview relevance
The topic is asked to check whether you separate the contract from the implementation and can reason about reliable exchange. A candidate who explains idempotency as "a unique key makes N identical requests have the effect of one" immediately gets ahead of "well, it's when a request can be repeated".
Typical checks:
- The HTTP message structure and the meaning of the code classes (
4xxclient,5xxserver). - The difference between
PUT(full replace, idempotent) andPATCH(partial update), and whyPOSTis not idempotent. - That REST is a style, not a protocol, and its key constraints.
- When to prefer
gRPCorGraphQL, and whatXSD/WSDL/json-schemadescribe.
Common wrong answer: "REST is a protocol like SOAP, just lighter". In fact REST is a set of recommendations over HTTP; real APIs follow its constraints to varying degrees, and a strict WSDL contract is exactly the SOAP story.