What HTTP Can Teach Us About Better Human Communication

Carl Chesser @che55er | che55er.io

🧪

The Year Was 1989

At CERN in Geneva, software engineer Tim Berners-Lee was facing a problem that had little to do with e-commerce or social media.

The challenge was collaboration.

🚀

HTTP Was Born

Tim Berners-Lee's early HTTP was a tiny request/response idea with one basic operation:

No status codes, no headers, if you could connect, you could get information.

RFC 9110 describes HTTP as beginning in 1990 as a simple low-latency GET mechanism.

📈

Then the Web Got Complicated

• HTTP/0.9 was enough for simple retrieval.
• HTTP/1.0 added the language needed for richer information exchange: methods, headers, metadata, and status codes.

"Creating the web was really an act of desperation..."

Tim Berners-Lee, reflecting on information-sharing difficulty at CERN.

🔁

The Real Problem

Human communication is complex. Our contracts are often vague.

Vague contracts create expensive retries.

📋

Make The Request Contract Explicit

Good APIs define behavior up front.

• Intent: "i need information on..."
• Payload:"why I need this information..."
• Definition of done: what "complete" means for getting info

⏱️

Define Response Timing Up Front

• Ack SLA: "You will hear back within X hours"
• Update cadence: "If pending, updates every X hours/days"
• Delivery window: "Expected result by [date + time]"

📣

Be Explicit About The Next Response

Vague acknowledgement creates polling.

Including when the response will be returned in the acknowledgment lowers the cost of communication.

🧭

What a Next Update Time Contains

• When: an exact time or date, not "soon"
• What: decision, progress note, blocker
• Fallback: what happens if there is no progress yet

By including what your response will contain, you help the requester understand the scope.

HTTP Status As Human Signal

202 Accepted

"I heard you, but it's still in progress."

Use it with a next update time.

💡

Why 202 Exists

HTTP needed a way to say: "I accepted this, but the work is not done yet."

It was built for asynchronous work so connections could quickly be freed (efficiency).

RFC 9110 describes 202 as intentionally noncommittal and points to status monitors or fulfillment estimates.

✅

202 Accepted: Useful Pattern

The update promise is the important part.

🕒

Fallback Path Example

"If this becomes urgent before then, use the incident channel."

A fallback path tells people what to do before the next scheduled update.

HTTP Status As Human Signal

301 Moved Permanently

"The owner or support path changed."

Helpful response: "I no longer support this. Please contact the platform team in #platform-help for future requests."

HTTP Status As Human Signal

429 Too Many Requests

"I'm overloaded right now."

Use it with a reset time or a smaller request.

🚦

Why 429 Exists

429 Too Many Requests was added later, in April 2012, in RFC 6585 to make rate limiting explicit.

The request may be valid, but there are too many requests in a period of time.

RFC 6585 specifies 429 responses can include details and a Retry-After header.

HTTP Status As Human Signal

503 Service Unavailable

"I'm out of the office until June 3rd."

Automatic signals help others know when you are unavailable to respond.

🔄

Polling vs Predictability

Without contract: "Just checking in on that earlier email..."

With contract: The requester knows when to expect a response and does not have to poll.

When timing is explicit, clients stop polling.

🛠️

Start This Week

1. When acknowledging work, include what you will do and when you will respond.
2. Consider what are valid fallbacks to include in communication.
3. Use out of office email status / Slack status to communicate when you can't respond (503).

Clear expectations are the fastest way to reduce uncertainty and noise.

Thank You

Carl Chesser @che55er | che55er.io

References