ProtocolLab
0%
Interactive Learning · 2026 edition

Two protocols. One playground.

A hands-on tour through REST APIs — the lingua franca of the web — and the Model Context Protocol — how AI assistants talk to the world. Read short lessons, click through real examples, simulate live requests, and prove you got it with quizzes.

11lessons
4interactives
23quiz questions
~45 minto finish
Module 1 · ~20 min

REST APIs

The architectural style that powers Stripe, GitHub, Twitter, your weather app, and basically the internet.

Begin →
Module 2 · ~20 min

Model Context Protocol

The open standard that lets AI applications plug into tools, data, and workflows — like USB-C for AI.

Begin →
Apply · ~5 min

Playground & Quiz

Build sample requests, simulate JSON-RPC handshakes, and put your knowledge to the test.

Open →
How to learn here. Read the lesson, click the interactive widgets, hit Mark lesson complete, then use the Next button to advance. Your progress is saved locally.
Keyboard. J next section · K previous · / jump to status-code search · ? show shortcuts.
Prelude

The 60-second crash course

Before we dive in, here's the minimum vocabulary you need.

ClientThe thing making the request (your browser, an app, an AI assistant).
ServerThe thing that responds with data or performs an action.
RequestA structured message: "please do X with Y".
ResponseA structured reply: data, success/failure, plus metadata.
ProtocolThe agreed-upon rules so both sides can understand each other.
ResourceAny thing you can name — a user, an order, a file, a weather forecast.
HTTPThe request/response protocol the web is built on. REST rides on HTTP.
JSON-RPC 2.0A tiny "call this method with these params" wire format. MCP rides on JSON-RPC.
💡
Mental model. REST is how a browser or app talks to a server. MCP is how an AI assistant talks to the world. Both follow the same instinct: standardize the conversation so anyone can plug in.
Module 1 · Lesson 1 · ~3 min

What is a REST API?

You'll learn:
  • What REST actually stands for — and where it came from.
  • The four pillars of a REST request: client, URL, method, representation.
  • How to read a raw HTTP request/response pair.

REST (REpresentational State Transfer) is an architectural style for building networked applications, introduced by Roy Fielding in his 2000 dissertation. It is not a protocol or a standard — it's a set of constraints that, when followed, produce systems that are simple, scalable, and reliable.

Most "REST APIs" you'll meet in the wild are HTTP APIs that follow most of these constraints. The pattern is the same everywhere: a client sends an HTTP request to a URL identifying a resource, using an HTTP method that describes the intent, and gets back a representation (usually JSON).

A typical REST request
GET /api/users/42 HTTP/1.1
Host: api.example.com
Accept: application/json
Authorization: Bearer eyJhbGciOi...
…and the response
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: max-age=60

{
  "id": 42,
  "name": "Ada Lovelace",
  "email": "ada@example.com",
  "_links": {
    "self":   { "href": "/api/users/42" },
    "orders": { "href": "/api/users/42/orders" }
  }
}
Key takeaway

A REST request is just method + URL + headers (+ body). The response is status + headers + body. Everything else in this module is detail on those four moving parts.

Module 1 · Lesson 2 · ~4 min

The six guiding constraints

Click any constraint to expand the explanation. Five are required for "RESTful"; one is optional.

1Uniform interfaceEvery resource is identified the same way and acted on through standard methods.

One consistent way to identify, manipulate, and describe resources. In an HTTP-based REST API this means standard URIs, standard methods (GET/POST/PUT/DELETE), self-descriptive messages (headers like Content-Type), and ideally HATEOAS — responses contain links that drive what the client can do next.

2Client–serverSeparation of concerns. UI lives client-side; data lives server-side.

The client (UI/UX) and the server (data/business logic) evolve independently. As long as the contract — the API — stays stable, either side can change without breaking the other. This is what lets you have web, iOS, Android, and CLI clients all hitting the same backend.

3StatelessEvery request must be self-contained — no server-side session memory.

Each request from a client carries everything the server needs to understand it. The server stores nothing between requests. This makes the system massively scalable: any server in a fleet can answer any request. (Application state lives in the client; resource state lives in databases.)

4CacheableResponses say whether (and how long) they can be reused.

Responses declare their cacheability via headers like Cache-Control, ETag, and Expires. Smart caching is one of the reasons the web scales — the response to "give me CNN's homepage" can be served from a CDN to millions of people without ever touching the origin server.

5Layered systemA client doesn't know — or care — what's behind the server it's talking to.

You can stack proxies, gateways, load balancers, and caches in front of the actual server. The client only sees the outer layer. This lets architects add security boundaries, scale horizontally, and migrate backends invisibly.

6Code on demand (optional)Servers may ship executable code (JavaScript) to extend the client.

The only optional constraint. The server can extend client functionality by sending code (the most familiar example: a server returning HTML that includes <script> tags). Useful, but most pure JSON APIs ignore this constraint entirely.

Key takeaway

Memorize the acronym U-S-C-L-C: Uniform interface · Stateless · Cacheable · Layered · Client-server. Code on demand is optional. Most production APIs ignore HATEOAS, technically making them "RESTish" rather than fully RESTful — and that's fine for most use cases.

Module 1 · Lesson 3 · ~4 min

HTTP methods — the verbs of REST

Tap a method to see what it does, when to use it, and a real example. Defined in RFC 9110.

Key takeaway

You only need four methods 90% of the time: GET reads, POST creates, PUT/PATCH update (replace vs. partial), DELETE removes. HEAD/OPTIONS are utility methods; TRACE/CONNECT are niche.

Module 1 · Lesson 4 · ~4 min

Status codes, decoded

Type a status code or pick one from the grid. Each lives in one of five families.

1xx Informational
2xx Success
3xx Redirection
4xx Client error
5xx Server error
📖
Naming gotcha. RFC 9110 (the current HTTP semantics spec, 2022) renamed two codes: 413 Payload Too Large413 Content Too Large, and 422 Unprocessable Entity422 Unprocessable Content. Old names still work everywhere; you'll see both in the wild.
Module 1 · Lesson 5 · ~3 min

Idempotency & safety

Two production-grade concepts that decide whether retrying a request is safe.

Two concepts trip people up constantly. They're easy once you have a mental model.

Safe

The method does not change server state. Calling it a million times leaves the world unchanged.

Safe methods: GET, HEAD, OPTIONS, TRACE

Idempotent

Calling the method multiple times has the same final effect as calling it once.

Idempotent: GET, HEAD, OPTIONS, TRACE, PUT, DELETE

All safe methods are idempotent; the reverse is not true.

MethodSafe?Idempotent?Why
GETReads only. Repeating it doesn't change anything.
POSTCreates a new resource each call.
PUTSets the resource to a value. Setting it twice still leaves it at that value.
PATCH❌*Partial update. {"counter": +1}-style patches are NOT idempotent.
DELETEResource gone after one call. Calling again → still gone.
HEADHeaders only — read-only, no state change.
OPTIONSCapability probe — never alters state.
⚠️
Real-world tip. Payment APIs (Stripe, Square, etc.) accept an Idempotency-Key header so that retrying a POST /charges after a network hiccup won't charge the customer twice. Idempotency is one of the most important production concepts in API design.
Key takeaway

SafeIdempotent. Safe methods (GET, HEAD, OPTIONS, TRACE) never change state. Idempotent methods (add PUT, DELETE) may change state, but repeating them lands the world in the same place. POST and PATCH are neither — add an Idempotency-Key header if you need retry safety on those.

Module 1 · Interactive · ~3 min

Build a REST request

Pick a method, type a URL, add headers and a body. Watch the raw HTTP request build itself.

Raw HTTP request
Module 2 · Lesson 1 · ~4 min

What is the Model Context Protocol?

You'll learn:
  • The problem MCP solves: the M-by-N integration explosion.
  • Where MCP came from and which AI vendors have adopted it.
  • How MCP differs from a traditional REST API.

MCP is an open standard, introduced by Anthropic on November 25, 2024, for connecting AI applications to external systems — data sources, tools, and workflows. Think of it as USB-C for AI: one consistent plug, hundreds of compatible devices.

Without MCP, every AI application needs custom integrations for every external system it wants to use. With MCP, an AI app and a service speak the same protocol, so you "build once and integrate everywhere". The protocol takes direct inspiration from the Language Server Protocol (LSP), which solved the same M-by-N integration explosion for code editors and language tooling.

Adoption since launch: OpenAI (March 2025), Google DeepMind (April 2025), plus Microsoft, GitHub, Cursor, Sentry, Zed, Replit, and hundreds of community servers. The current stable spec is 2025-11-25; a release candidate 2026-07-28 introduces a stateless transport and server-rendered MCP Apps.

For developers

Build one MCP server and any compatible AI app (Claude, ChatGPT, VS Code, Cursor…) can use it.

For AI apps

Tap into an entire ecosystem of tools, data, and workflows without bespoke integration code.

For users

Smarter assistants that can read your calendar, query your database, and run real actions on your behalf.

🧩
Compared to REST: A REST API is a static contract — the client must be coded to know about each endpoint. MCP is discoverable: the client asks the server "what can you do?" at runtime and the LLM decides what to call.
Key takeaway

MCP is to AI integrations what LSP was to language tooling: a single shared protocol that turns an M × N integration problem (M apps × N services) into M + N.

Module 2 · Lesson 2 · ~4 min

Architecture: host, client, server

MCP uses a client-server architecture with three participants. A single AI application (the host) can speak to many MCP servers at once, opening one dedicated client per server:

MCP Host e.g. Claude Desktop, VS Code, Cursor
Client A
Client B
Client C
Filesystem Server stdio · local
GitHub Server HTTP · remote
Sentry Server HTTP · remote
HostThe AI application — Claude Desktop, VS Code, Cursor. Manages the whole UX and coordinates multiple clients.
ClientA connector inside the host. One client per server. Maintains the live connection.
ServerA program that exposes capabilities (tools, resources, prompts). Can run locally or remotely.

MCP has two conceptual layers:

  • Data layer — the JSON-RPC 2.0 protocol: lifecycle, capability negotiation, primitives (tools, resources, prompts), and notifications.
  • Transport layer — how messages travel: stdio for local subprocesses, Streamable HTTP for remote servers (HTTP POST plus optional Server-Sent Events).
🔐
Authorization. Remote MCP servers use the OAuth 2.1 framework (with PKCE) plus OpenID Connect for user authentication. The 2025-11-25 spec also defines protected-resource metadata so clients can discover the right authorization server automatically.
Key takeaway

Host = the app you open. Client = an in-app connector (one per server). Server = the program exposing tools/resources/prompts. Wire data through the data layer (JSON-RPC) over a transport (stdio or Streamable HTTP).

Module 2 · Lesson 3 · ~4 min

The three server primitives

Everything an MCP server can offer reduces to one of these three things. Each has a different control model: who decides when it runs?

🛠️

Tools

Model-controlled

Functions the LLM can call to take actions. Search flights, send a Slack message, query a DB.

tools/listtools/call
📄

Resources

Application-controlled

Read-only data the app pulls in as context. File contents, DB schemas, API docs, calendar entries.

resources/listresources/readresources/subscribe
📝

Prompts

User-controlled

Pre-built templates the user explicitly picks. Slash commands like /plan-vacation.

prompts/listprompts/get
Key takeaway

Servers expose three primitives, each with a different driver: Tools (LLM picks), Resources (app injects), Prompts (user invokes). Memorize the control model — it dictates UX and security policy.

Client primitives

Servers can also ask the client to do things:

Sampling

The server asks the host's LLM to generate text. Lets servers stay model-agnostic.

sampling/createMessage

Elicitation

The server asks the user for more info or confirmation mid-flow.

elicitation/create

Roots

The client tells the server which directories or scopes it can touch.

roots/list
Module 2 · Lesson 4 · ~3 min

Transports: stdio & Streamable HTTP

The same JSON-RPC messages flow over one of two transports. Local or remote — that's the choice.

Local

stdio

The host spawns the server as a subprocess and communicates over standard input/output. Zero network overhead, ideal for local tools like a filesystem server.

// Host launches server, then talks via stdin/stdout
{
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/docs"]
}
Remote

Streamable HTTP

HTTP POST for requests, optionally with Server-Sent Events for streaming. Supports bearer tokens, OAuth, and standard auth headers. Used by hosted servers like Sentry's MCP.

POST /mcp HTTP/1.1
Host: mcp.sentry.io
Authorization: Bearer sk_live_...
Content-Type: application/json
Accept: application/json, text/event-stream

{"jsonrpc":"2.0","id":1,"method":"tools/list"}
Key takeaway

Same protocol, two pipes. Use stdio when the server runs on your machine (filesystem, git, local shell). Use Streamable HTTP when the server lives behind a URL with auth (Sentry, GitHub, Linear, internal SaaS).

Module 2 · Interactive · ~3 min

JSON-RPC handshake simulator

Walk through a real MCP client-server conversation, message by message. Click Next step to advance.

CLIENT
Claude Desktop Acts as MCP client
SERVER
Weather MCP Provides weather tools
Transcript Step 1 of 6

Quick reference · 1 min

Cheat sheet

Print-friendly summary of everything in both modules.

REST in 6 lines

  • Verbs: GET (read) · POST (create) · PUT (replace) · PATCH (modify) · DELETE.
  • Safe: GET, HEAD, OPTIONS, TRACE.
  • Idempotent: safe ones + PUT, DELETE.
  • Status families: 2xx OK · 3xx redirect · 4xx you · 5xx server.
  • Caching: Cache-Control, ETag, If-None-Match → 304.
  • Retry-safe POST: Idempotency-Key header.

MCP in 6 lines

  • Wire: JSON-RPC 2.0 over stdio (local) or Streamable HTTP (remote).
  • Spec: current 2025-11-25; next RC 2026-07-28.
  • Server primitives: Tools (LLM), Resources (app), Prompts (user).
  • Client primitives: Sampling, Elicitation, Roots.
  • Lifecycle: initialize → notifications/initialized → use → shutdown.
  • Discovery: tools/list, resources/list, prompts/list.
Apply · 2

REST vs MCP — side-by-side

AspectREST APIMCP
PurposeApp ↔ server communicationAI app ↔ tools/data communication
Wire formatHTTP + JSON (usually)JSON-RPC 2.0 over stdio or HTTP
IdentificationURLs (resources)Method names + primitive IDs
DiscoveryOut-of-band (OpenAPI, docs)In-protocol (*/list at runtime)
StateStateless (per request, by constraint)Stateful today (2025-11-25); stateless RC ships 2026-07-28
AuthAnything HTTP allows (Bearer, OAuth, mTLS, API keys…)OAuth 2.1 + OIDC for remote; client-managed for stdio
StreamingSSE / WebSockets (bolted on)First-class via notifications / SSE
Designed forHumans + appsLLMs + apps
Year introduced2000 (Fielding)Nov 25, 2024 (Anthropic)
🔑
Key insight. MCP doesn't replace REST. Many MCP servers wrap REST APIs — they translate the static REST contract into the discoverable, LLM-friendly MCP primitives. Learn both: REST powers the web, MCP powers the AI layer on top of it.
Apply · 3 · ~2 min

Live API playground

Fire a real GET request against a public, no-auth API (JSONPlaceholder). Inspect the live response.

Awaiting request…
// Click "Send request" to fetch real data
Apply · 4 · ~7 min

Final quiz

23 questions across both modules. No time limit. Pass = 80%. Each answer comes with an explanation.

0 / 0 answered
Going further

Where to read next