HTTP beyond HTML

From HTML to diverse data

Early HTTP/0.9 used a simple GET and returned HTML without response headers. HTTP/1.0 introduced status lines and headers describing media types, supporting content beyond HTML.

Design cues

• HTTP/1.0 and later use Content-Type to describe content. Modern examples include text/html, image/png, and application/json; this does not mean JSON existed in early HTTP.
• Methods and headers keep it extensible; POST/PUT/DELETE, Cache-Control, etc., fit in without breaking the model.
• Full name: HyperText Transfer Protocol. “HyperText” got the spotlight, but the protocol itself is pretty versatile.
• HTTPS provides encrypted, authenticated HTTP communication. HTTP/1.1 and HTTP/2 use TLS; HTTP/3 uses QUIC integrated with TLS 1.3. Encryption alone does not guarantee truthful content or a trustworthy site.

Non-HTML is normal now

HTTP supports non-HTML uses such as APIs and file delivery. APIs are not required to use JSON.

Common non-HTML cargo

• JSON/XML Web APIs and webhooks (application/json, application/xml).
• File delivery (image/png, application/pdf, application/zip, etc.).
• SSE carries events in a text/event-stream HTTP response. WebSocket is a separate protocol using its own frames after establishment, such as via HTTP/1.1 Upgrade.
• GraphQL or gRPC-web: protocols riding on HTTP as the transport.

Flexibility mechanisms 🤝

Headers and negotiation make HTTP adaptable. Content-Type/Accept are the brokers.

Content negotiation

• Clients ask via Accept; servers state via Content-Type.
• Language/encoding negotiation lives in Accept-Language / Accept-Encoding.
• If an acceptable representation is unavailable, a server may return 406 or disregard the preference and send an available representation. Clients should check the actual Content-Type.

Methods and bodies

• GET/HEAD fetch; POST creates/sends; PUT/PATCH/DELETE update or remove.
• Body rules depend on the method and status. GET request bodies have no generally defined semantics; HEAD responses, 204, and 304 cannot contain content. Content-Type does not override those rules.

Practical tips 💡

A little HTTP etiquette goes a long way beyond “just return JSON.”

Recommended handling

• Set Content-Type/Accept correctly (application/json, proper MIME for binaries).
• Use standard status codes (200/201/204, 4xx/5xx). Document any nonstandard behavior.
• Leverage Cache-Control and ETag; even APIs benefit when GET responses are cacheable.
• If errors are JSON, standardize the shape (e.g., message + code).

Common gotchas

• Missing or wrong Content-Type leads to parse failures.
• Middleware written for HTML might rewrite or wrap API responses unexpectedly.
• Returning HTML to a JSON-seeking client can trigger odd behavior—oops.

Easy takeaway

Modern HTTP carries many formats under common method and content rules. Continue with method semantics, version differences, and caching conditions.

Specifications

HTTP/0.9 / RFC 1945 / RFC 9110 §6.4 / §12 / HTML: Server-sent events / RFC 6455