- In short
- A websocket keeps a persistent, bidirectional connection open for continuous, low-latency exchange, which suits ongoing realtime streams. Request-response HTTP suits discrete calls that begin and end. Transport choice follows the interaction pattern you need, not any change in what the model is capable of producing.
Two shapes of connection
Once you know that a client SDK is a thin wrapper over an HTTP API, the next technical-fundamentals idea for the Claude Certified Developer - Foundations (CCDV-F) exam is that not every interaction fits the same connection shape. There are two shapes to know. Request-response HTTP opens a connection, sends one request, receives one response, and closes: a discrete transaction with a clear beginning and end. A websocket instead keeps a single connection open and lets both sides send messages continuously in both directions for as long as the connection lives.
The knowledge point is recognising which shape a given interaction needs. It is not that one transport is modern and the other is legacy, or that one is universally faster. They serve different interaction patterns, and choosing well means reading the pattern, not reaching for the fancier-sounding option.
- Websocket
- A transport that establishes a single persistent, bidirectional connection between client and server. Once open, either side can send messages at any time with low overhead, making it suited to continuous realtime exchange rather than one-off calls.
What a websocket gives you
A websocket's defining traits are that it is persistent and bidirectional. Persistent means the connection stays open rather than being torn down after each message, so you avoid repeatedly paying the setup cost of a fresh connection. Bidirectional means either side can push a message whenever it has one, rather than the client always having to ask first. Together these make websockets suited to continuous, low-latency exchange: interactions where messages flow back and forth over a sustained period and where the overhead of re-establishing a connection each time would hurt.
That is the profile of an ongoing realtime stream. A live, interactive session where small messages pass frequently in both directions benefits from a connection that is already open and ready. The value is in the sustained, low-latency, two-way flow, which a series of independent request-response calls would serve clumsily.
What request-response HTTP is good for
Request-response HTTP is the right shape for discrete calls: an interaction that is naturally one question and one answer, with nothing ongoing to maintain between them. You send a request, you get a response, and the exchange is complete. Most integrations are exactly this shape. Asking the model to summarise a document, classify a ticket, or answer a single query is a discrete transaction, and request-response HTTP models it cleanly with no persistent connection to manage.
The CCDV-F exam's central trap here is reaching for websockets when simple request-response HTTP meets the need. A persistent bidirectional connection is more machinery: it has to be opened, kept alive, monitored, and torn down, and it carries operational complexity that a stateless request-response call avoids. If the interaction is discrete, that machinery is cost without benefit. The disciplined default for one-off calls is request-response HTTP; you move to a websocket only when the interaction is genuinely a continuous, low-latency stream that warrants a persistent connection.
Transport does not change capability
The second grounded fact this knowledge point tests is that transport choice follows the interaction pattern, not model capability. Choosing a websocket does not give the model new powers, and choosing request-response HTTP does not take any away. Transport is about how data moves between your client and the server, not about what the model can produce. The same model, asked the same thing, yields the same range of output regardless of the pipe the bytes travel through.
This mirrors the lesson from SDKs that wrap the REST API: just as an SDK is an ergonomics layer that adds no capability, transport is a delivery choice that adds no capability. Both are decisions about developer experience and interaction shape, not about the model. When a question implies that switching transports would change what the model can do, that is the distractor to reject. And because transport does not touch capability, the token and context-window rules hold identically over a websocket or a plain HTTP call.
Why this knowledge point matters
This concept sits at Bloom level understand and difficulty 2. You are expected to explain when a persistent websocket transport is appropriate versus request-response HTTP, and to reason about the trade rather than memorise a rule. It builds on the SDK knowledge point and feeds into applied integration through a client SDK, where you make concrete choices about how an application talks to the model. Hold two things and the questions become easy: websockets are for continuous, low-latency, bidirectional streams, and transport is a delivery decision, not a capability decision.
Worked example
A team building a simple document-summarisation endpoint proposes a websocket architecture, adding complexity the use case never needed.
The team is building an internal tool where a user uploads a document and gets back a summary. An engineer, having read that websockets are good for realtime, proposes running the whole thing over a persistent websocket connection, reasoning that it will feel more responsive.
This is the over-engineering trap exactly. Summarising a document is a discrete interaction: one request in, one summary out, with nothing ongoing to maintain between calls. A persistent bidirectional connection adds machinery, opening, keeping alive, monitoring, and closing the socket, that this pattern never needs. Request-response HTTP models the transaction cleanly and with far less operational burden.
There is a second confusion to clear up. The engineer half-believed the websocket would make the summary "better" or the model faster. It would not: transport choice follows the interaction pattern and does not change what the model produces. If the team wants the summary to appear progressively as it is generated, that is a streaming concern handled over the existing request-response call, not a reason to adopt a persistent bidirectional socket. The right architecture is the simple one: request-response HTTP for a discrete call, with websockets reserved for a genuinely continuous, low-latency stream that does not exist here.
Common misreadings to avoid
Misconception
Websockets are the modern choice, so I should use them for all my model interactions.
What's actually true
Misconception
Switching to a websocket transport will make the model faster or more capable.
What's actually true
How it shows up on the exam
CCDV-F questions here describe an interaction and ask which transport fits, or describe a design that reached for websockets and ask what is wrong. A discrete one-call-one-answer scenario points to request-response HTTP; a continuous, low-latency, two-way stream points to a websocket. Any suggestion that transport changes model capability is a distractor. The two grounded rules, match the transport to the interaction pattern, and transport does not change capability, decide every version of the question.
A developer is choosing a transport for a feature where a user submits one prompt and receives one answer, with no ongoing session. They are tempted by websockets 'for performance.' What is the best guidance?
People also ask
When should you use websockets instead of HTTP?
Does the transport change what the model can produce?
What is a persistent bidirectional connection?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
No videos curated for this concept yet
We are still curating the best official and community videos for this topic.
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.