Modern API Architecture: REST, GraphQL & gRPC

Contract-First Schemas, Authentication, Rate Limiting & Tracing

An API design course as IDE-style videos, built from one set of lesson scripts and one small service. 8 modules, 40 lessons, five to ten minutes each.

Intermediate · 2 hours · 40 lessons · 36 labs

Who it is for

Intermediate level.

For developers who build or call web services and want APIs that survive retries, change and heavy use: HTTP done properly, REST, authentication, versioning, and when GraphQL or gRPC fits better.

What you don't need yet:

• You don't need to know GraphQL or gRPC yet
• No security background: tokens, OAuth and scopes are explained
• No cloud account: one small sample service is used throughout

What helps:

• HTTP basics: what a request and a response are
• Some Python or Node.js: a few labs read a small Python service

Before you start:

• HTTP protocol basics
• Node.js or Python API development

Take first:

• Hands-on Python: Complete Video Course & Book — Beginner
• PostgreSQL, Indexing & Relational Data Modeling — Beginner

Take next:

• Scalable System Design & Distributed Architecture — Advanced
• AI Engineering: LLM Apps, RAG & Agents — Intermediate
• Application Security & Threat Modeling for Engineers — Advanced

Learning paths:

• Distributed Systems & Backend Architecture
• Offensive Security Foundations (Red Team)
• AI Engineering

Nobody needs to know everything before they start. Each course builds on the one before, so a learning path takes you there step by step.

Labs

36 labs, 16 of them graded: you write the code, it runs, and graded labs check the result. The outline lists each lesson's labs.

What is free

Start free: First module free with an account. Pro: Every course, lab, handbook, practice exam and certificate.

• Pro monthly — $29 a month. Every course, lab, handbook, practice exam and certificate
• Pro yearly — $249 a year. Every course, lab, handbook, practice exam and certificate

Course outline

What An API Is And HTTP For Real

1. What An API Is, And The Alternatives (5 labs): You can say what an API is in terms of a contract rather than a technology, read a whole HTTP response off the screen part by part, name which version of HTTP you are speaking and why that matters, and place SOAP, GraphQL and gRPC as alternatives you will compare properly at the end of the course.
2. HTTP Methods And Status Codes (6 labs): You can choose the method that matches what a request really does, say which methods are safe and which are idempotent, read a status code as a family and then as a specific promise, and recognise the damage done by a service that answers the wrong status.
3. Headers And Content Negotiation (6 labs): You can name what each header on a real response is for, negotiate a representation with Accept and read the Vary header that makes that negotiation cacheable, tell Content-Type from Accept, and decide whether a value belongs in the path or the query string.
4. Caching And Conditional Requests (5 labs): You can choose a cache policy, explain freshness and validation, use an ETag with conditional requests, and recognise why a missing validator wastes bandwidth and permits stale updates.
5. Cookies And CORS (4 labs): You can explain a cookie backed session, choose its security attributes, read a browser preflight, and distinguish a browser origin policy from server side authentication.

REST And Resource Modelling

1. The REST Constraints (1 lab): You can explain the REST constraints, distinguish a resource from a route, and judge a simple JSON API by the uniform interface it gives every client.
2. Naming Resources And Collections (1 lab): You can name collections and items consistently, choose path segments for identity, and reject verbs, case surprises, and database names in public URIs.
3. Sub-resources And Relationships (1 lab): You can model related resources, choose between embedding and linking, and avoid paths whose depth makes ownership and change unclear.
4. Actions That Do Not Fit CRUD (1 lab): You can model an action that does not fit CRUD as a resource or state transition, choose a useful status, and make long running work observable.
5. HATEOAS And Hypermedia (1 lab): You can use links as part of a representation, explain how hypermedia reduces client coupling, and distinguish a server supplied link from a guessed URI.

Request And Response Design

1. Pagination Strategies (1 lab): You can choose offset or cursor pagination, return stable page metadata, and prevent duplicates and gaps when a collection changes while a client walks it.
2. Filtering And Searching (1 lab): You can design filter parameters, distinguish exact filtering from text search, validate unsupported values, and keep filtered pages predictable.
3. Sorting Results (1 lab): You can expose a safe sort vocabulary, make ordering deterministic, and explain why pagination and sorting must be designed together.
4. Large Payloads And Streaming (1 lab): You can choose pagination, streaming, or a job for large results, and explain the memory and failure tradeoffs of each response style.
5. Partial Responses (1 lab): You can design field selection and sparse representations without making hidden server calls, and keep partial responses safe, cacheable, and understandable.

Correctness Under Retry And Failure

1. Error Handling And Safe Retries: You can classify client and server failures, choose retryable statuses, and make a retry policy bounded and observable.
2. Problem Details: RFC 9457: You can return an RFC 9457 problem detail, explain that it obsoletes RFC 7807, and keep error types stable while details remain useful.
3. Idempotency Keys: You can use an idempotency key for an uncertain create, bind it to the request body, and return the original result on a safe replay.
4. Rate Limiting Strategies: You can choose a rate limit scope, return a useful rejection, and distinguish throttling from an authorization failure or a server outage.
5. Versioning APIs: You can choose a versioning boundary, evolve a response compatibly, and plan deprecation so clients have time to move.

Authentication And Authorisation

1. Basic Auth, Tokens And Sessions: You can distinguish basic credentials, bearer tokens, and sessions, and choose where each fits in an HTTP API.
2. JSON Web Tokens: You can read JWT parts, verify the signature and algorithm before trusting claims, and reject a tampered token.
3. OAuth Two And OpenID Connect: You can distinguish delegated authorisation from identity, name the main OAuth roles, and explain what OpenID Connect adds.
4. RBAC Contrasted With ABAC: You can compare role based and attribute based policies, choose a useful boundary, and explain why authentication data is not enough without policy context.
5. Scopes And Key Rotation: You can design narrow scopes, check them at the resource boundary, and rotate signing keys without trusting arbitrary key material.

Documentation And Contract

1. OpenAPI And Design-First: You can use OpenAPI as a design contract, review paths and schemas before code, and keep documentation honest as the service evolves.
2. Unit And Integration Testing: You can place a check at the right boundary, combine unit and integration tests, and use functional requests to verify public behaviour.
3. Mocking Dependencies: You can mock a dependency at a clear boundary, avoid false confidence, and reserve live integration checks for behaviour a mock cannot prove.
4. Contract Testing: You can test an API against its OpenAPI promise, distinguish provider and consumer checks, and detect drift before deployment.
5. Load Testing: You can design a useful load test, distinguish throughput from latency, and use measured limits to guide API performance work.

Beyond Request And Response

1. Webhooks Versus Polling: You can choose polling or webhooks, secure a delivery endpoint, and make webhook handling retryable and duplicate safe.
2. WebSockets: You can explain the WebSocket handshake, choose a message protocol, and plan authentication, backpressure, and reconnect behaviour.
3. Server-Sent Events: You can describe an SSE stream, use event identifiers and retry hints, and choose SSE when updates flow from server to client.
4. Event-Driven Architecture And Queues: You can separate synchronous acknowledgement from asynchronous work, design a durable event, and reason about queues, retries, and ordering.
5. API Gateways And Proxies: You can define a gateway boundary, assign it cross cutting concerns, and avoid hiding service ownership behind an untestable proxy layer.

Operating An API

1. Security Best Practices: You can identify common API vulnerabilities, set safe defaults, and make security controls part of the contract and deployment path.
2. Performance Optimization: You can measure API cost, find an N plus one query, and choose an optimisation that improves the bottleneck without changing the contract.
3. Observability: Logs, Metrics, Traces: You can use structured logs, service metrics, and traces together to explain one API request and detect failure trends.
4. Handling PII And Data Privacy: You can minimise personal data, protect it in transit and at rest, and design API responses and logs that respect retention and access rules.
5. When Each Wins: REST, GraphQL, gRPC And SOAP: You can compare REST, GraphQL, gRPC, and SOAP by constraints and choose a style that fits clients, networks, governance, and operations.