Technical interview guide

API Design & REST Fundamentals

Designing HTTP APIs that are predictable to call and safe to retry — resource modeling, status codes, versioning, and idempotency.

Read: 23 min
Practice MCQs: 25
Interview QA: 25
Edition: v3
Editorial status: Reviewed
Relevant for: AI EngineerAgentic AI EngineerBackend EngineerBlockchain DeveloperCloud ArchitectCybersecurity EngineerData ArchitectData EngineerDevOps EngineerForward Deployed Engineer (FDE)Frontend EngineerFull-Stack DeveloperIdentity and Access Management (IAM) EngineerMachine Learning EngineerPlatform EngineerSecurity ArchitectSite Reliability EngineerSoftware EngineerSolutions ArchitectTechnical Product Manager

Scope: HTTP Semantics RFC 9110 and OpenAPI Specification 3.2.

Interview QA

Treat each question like a live interview question: answer out loud first (structure, assumptions, tradeoffs), then open the model answer to spot gaps and rehearse a tighter follow-up.

Curated: 2026-10-02 · Written: 2026-09-11 · Reviewed: 2026-10-03

QA-1

What is REST, and what do most so-called REST APIs actually implement?

QA-2

Explain safety and idempotency, and why they matter beyond documentation.

QA-3

How would you choose status codes for an API, and which distinctions matter most?

QA-4

How would you design pagination for a large collection endpoint?

QA-5

How would you version an API and manage breaking changes?

QA-6

How should an API report errors so clients can act on them?

QA-7

Explain how you would model an operation that is not naturally a resource.

QA-8

How would you handle concurrent updates to the same resource?

QA-9

What makes an API easy to consume, from a client developer's perspective?

QA-10

How would you protect an API from abuse and overload?

QA-11

Explain HTTP caching and how an API should use it.

QA-12

How would you design an endpoint for a long-running operation?

QA-13

What would you look for when reviewing an API design?

QA-14

Compare REST with GraphQL and gRPC, and say when you would choose each.

QA-15

How would you handle partial updates to a resource?

QA-16

How would you design an API's authentication and authorisation surface?

QA-17

Explain how an API description like OpenAPI changes how a team works.

QA-18

How would you decide what a resource should be in an unfamiliar domain?

QA-19

What is the cost of an API that is hard to change, and how do you reduce it?

QA-20

How would you test an HTTP API?

QA-21

How should an API communicate deprecation to its clients?

QA-22

What does it mean for an API to be well-observed in production?

QA-23

How would you design an API endpoint that returns data from several sources?

QA-24

Explain the trade-offs of exposing internal identifiers in an API.

QA-25