ゆるテックノート

HTTP beyond HTML (yes, always)

Full name: HyperText Transfer Protocol. People sometimes think “HTTP = HTML delivery,” but it was a general-purpose transport from day one. Today it usually rides over HTTPS (HTTP + TLS) and hauls JSON, binaries, and streams without blinking. A chill recap of how that happened.

Born as a general protocol 🧭

Early HTTP/0.9–1.0 was simple, but the payload was MIME-typed from the start. Not just HTML—surprise!

Design cues

  • Content-Type declares the payload: text/html, image/png, application/json—anything goes.
  • 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 = HTTP over TLS; encryption and certificates are now the default in practice.

Non-HTML is normal now

Modern workloads lean on HTTP for non-HTML content. “API over HTTP + JSON” is basically the default vibe.

Common non-HTML cargo

  • JSON/XML Web APIs and webhooks (application/json, application/xml).
  • File delivery (image/png, application/pdf, application/zip, etc.).
  • Streaming and events (text/event-stream for SSE, upgrades to WebSocket).
  • 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.
  • It’s basically “I’d like JSON” / “Cool, here’s HTML” / “Sure, have JSON,” depending on what’s available.

Methods and bodies

  • GET/HEAD fetch; POST creates/sends; PUT/PATCH/DELETE update or remove.
  • Both request and response bodies can carry arbitrary payloads—just declare Content-Type.

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

“HyperText” is in the name, but HTTP’s always been a general-purpose courier. HTML is just one of its many packages.