Out of the box, the official OpenAI and Anthropic Python SDKs talk HTTP/1.1, a protocol from 1997 (RFC 2068). Both build on HTTPX2, which leaves HTTP/2 off unless you turn it on (OpenAI SDK, Anthropic SDK, HTTPX2).
Streaming answers? When they stream over HTTP, both APIs use Server-Sent Events, a W3C standard since 2015 (OpenAI, Anthropic, W3C). Live voice? OpenAI recommends WebRTC for browser and mobile clients (OpenAI). Even MCP’s Streamable HTTP transport, which remote MCP servers use, sends HTTP POST requests, with SSE for streaming. Since the 2026-07-28 revision, each POST gets back either JSON or its own SSE stream, and the old always-open GET stream is gone (MCP).
Here are ten web standards and two patterns, with what each is good for in AI and where it falls short. Years mark standardization, not adoption. They don’t all compete: some are HTTP versions, others are transports, browser APIs or an authentication scheme, and several stack. HTTP/3 runs on QUIC (RFC 9114), and SSE works over any HTTP version.
SSE or WebSockets?
If only the server talks while an answer streams, SSE is often enough. Reach for WebSockets when both sides talk at once.
| Feature | SSE | WebSocket |
|---|---|---|
| Direction | Server to client | Both ways |
| Data | UTF-8 text | Text and binary frames |
| Runs over | An ordinary HTTP response | Its own protocol, after an HTTP upgrade |
| Use it for | Streamed answers, progress, notifications | Live sessions where both sides talk |
| Standardized | WHATWG HTML, W3C since 2015 | RFC 6455, in 2011 |
With SSE, the client still talks back, just with separate HTTP requests. Binary data has to be encoded as text first.
Pick by job
| You need to | Start with | Spec |
|---|---|---|
| Make one API or tool call at a time | HTTP/1.1 is fine | RFC 9112 |
| Stream a model’s answer, progress or notifications | SSE | WHATWG HTML |
| Run a live session where both sides talk | WebSocket | RFC 6455 |
| Add live voice or camera from a browser or phone | WebRTC | W3C |
| Make several API or tool calls at once to one origin | HTTP/2, or HTTP/3 on lossy networks | RFC 9113, RFC 9114 |
| Run a complex read-only search with a body | HTTP QUERY, once every hop supports it | RFC 10008 |
| Mix must-arrive results with droppable live updates | WebTransport | W3C CR |
| Show a site which agent is calling | Web Bot Auth | IETF draft |
| Follow a long job | Polling, or a webhook to your server | MCP Tasks, OpenAI |
Established
HTTP/1.1
1997 · Simple requests and responses, first specified in RFC 2068. RFC 9112 is the current version.
- Good for: single API calls and tool calls.
- Falls short: no multiplexing. Parallel requests usually need several connections, and pipelined responses still come back in order.
WebSocket
2011 · A two-way connection kept open, carrying text or binary frames (RFC 6455).
- Good for: live sessions where both sides talk, like server-side voice agents.
- Falls short: for one-way text streaming, SSE is often enough.
SSE
2015 · Text pushed from server to client over HTTP (WHATWG HTML).
- Good for: streamed answers, progress updates and notifications.
- Falls short: no binary messages, and no two-way traffic on the same stream.
HTTP/2
2015, updated 2022 · Many streams over one TCP connection. RFC 9113 replaced the original RFC 7540.
- Good for: an agent making several API or tool calls at once to the same origin. Native gRPC uses it (gRPC).
- Falls short: one lost TCP packet can delay every stream on that connection.
QUIC
2021 · Encrypted transport over UDP with independent streams (RFC 9000).
- Good for: a connection can survive a device changing networks, if the server allows it (§9). A lost packet holds up only the streams with data in it, which can be several, while the rest keep going (§13).
- Falls short: some networks block UDP. Fallback is up to the app (RFC 9114).
WebRTC
2021 · Real-time audio, video and data. It first became a W3C Recommendation in January 2021.
- Good for: live voice and camera with a model, from a browser or phone.
- Falls short: often unnecessary for text. It needs connection setup, and maybe a relay server.
HTTP/3
2022 · HTTP over QUIC instead of TCP (RFC 9114).
- Good for: it can cut setup time and cross-stream delays on lossy networks.
- Falls short: making the model faster.
New standard
HTTP QUERY
June 2026 · Like GET, but with a request body. It’s safe and idempotent (RFC 10008).
- Good for: complex read-only searches like AI retrieval, with safe retries and caching where supported.
- Falls short: relying on it before your whole stack supports it: client, CDN, proxies and server.
Still developing
WebTransport
W3C Candidate Recommendation · Reliable streams plus droppable datagrams. Major browsers have shipped it since March 2026; older ones and embedded webviews need a check (MDN).
- Good for: results that must arrive next to live updates that can go stale.
- Falls short: code that can’t absorb changes. The IETF protocol is still a draft (IETF).
Web Bot Auth
IETF draft · Signed requests that show a site which agent is calling.
- Good for: telling real agents from bots posing as them. Cloudflare already checks these signatures (Cloudflare).
- Falls short: deciding what an agent may do. It proves identity, not permission.
Patterns, not protocols
Polling
Asking the server again and again whether something changed.
- Good for: long AI jobs where checking every few seconds is fine, like MCP tasks. Where client and server support the Tasks extension, each job gets a handle to poll, and a client can pick it up again after reconnecting.
- Falls short: live updates. You either waste requests or lag behind.
Webhooks
An HTTP request a service sends you when something happens.
- Good for: telling your system that a batch run or agent task has finished. OpenAI, for one, sends them for batch and background jobs (OpenAI).
- Falls short: they can’t reach a browser tab directly. Receiving them is a small integration of its own: a server that verifies signatures, handles duplicate deliveries and passes the event on.
I first shared this list on LinkedIn on 20 October 2026. The maintained version, with the animated diagram, every source and the date I last checked them, is on argbe.tech.
