codingstairs
NotesEDULifeContact
⌕Search⌘K
koen

Navigation

  • Intro
  • Blog
  • Life

Get in touch

Send without signing in. Add your email if you'd like a reply.

  • Leave a message anonymously →
  • ✉ warragon112@gmail.com
  • KakaoTalk Open Chat ↗

© 2026 codingstairs

  • Notes
  • EDU
  • Search
  • Life
  • Contact
  • Legal
  • RSS
  • GitHub
Notes›web-fundamentals

HTTP and REST — The Client-Server Contract

Published 2026-04-28· Updated 2026-05-18·0 views

HTTP and REST — The Client-Server Contract

What does the browser ask the server for, and how does the server reply? Almost everything on the web sits on top of that simple question. This article covers HTTP's origins, methods and status codes, headers, REST's original meaning, and the changes brought by HTTP/2 and HTTP/3.

1. About HTTP and REST

HTTP stands for HyperText Transfer Protocol. Tim Berners-Lee proposed it at CERN in 1989, and after the 0.9 version in 1991 (one-line requests, HTML only), it was standardized as RFC 1945 (HTTP/1.0) in 1996 and RFC 2068 (HTTP/1.1) in 1997 (revised as RFC 2616 in 1999). HTTP/2 followed as RFC 7540 in 2015, and HTTP/3 as RFC 9114 in 2022.

REST stands for Representational State Transfer. It was defined in Roy Fielding's 2000 doctoral dissertation "Architectural Styles and the Design of Network-based Software Architectures". It is a different layer of concept from HTTP itself — closer to "an API design style that follows the web's good properties faithfully".

2. Request-Response Model

The client sends a request and the server returns a response. HTTP/1.1's keep-alive reuses the same connection, but processing remains serial. From HTTP/2, multiple requests can flow concurrently over a single connection.

GET /api/users/42 HTTP/1.1
Host: example.com
Accept: application/json
Authorization: Bearer eyJhbGciOi...

(빈 줄)
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 87

{"id":42,"name":"lee","email":"lee@example.com"}

3. Methods

Method Intent Idempotent Request body
GET Retrieve a resource yes Generally none
POST Create a resource / general action no Yes
PUT Replace a resource entirely yes Yes
PATCH Partially update a resource Generally no Yes
DELETE Delete a resource yes Generally none
HEAD Just headers of GET yes None
OPTIONS Methods / CORS preflight yes None

"Idempotent" means sending the same request multiple times yields the same outcome. Network retry policy depends on this property.

4. Status Codes

Three-digit numbers. The first digit categorizes:

Category Meaning Common codes
1xx Informational 100 Continue · 101 Switching Protocols
2xx Success 200 OK · 201 Created · 204 No Content
3xx Redirection 301 Moved Permanently · 302 Found · 304 Not Modified · 307 Temporary Redirect · 308 Permanent Redirect
4xx Client error 400 Bad Request · 401 Unauthorized · 403 Forbidden · 404 Not Found · 409 Conflict · 422 Unprocessable Entity · 429 Too Many Requests
5xx Server error 500 Internal Server Error · 502 Bad Gateway · 503 Service Unavailable · 504 Gateway Timeout

The difference between 401 and 403 confuses people often. 401 is "I don't know who you are (need authentication)", 403 is "I know you, but you lack permission".

5. Headers

Header Side Use
Content-Type Both Body format (application/json · text/html · multipart/form-data)
Accept Request Format the client wants
Authorization Request Auth (Bearer ..., Basic ...)
Cookie / Set-Cookie Request / response Cookie
Cache-Control Both Cache policy (no-store · max-age=3600)
ETag / If-None-Match Response / request Conditional request (304 if unchanged)
Location Response Redirect target
User-Agent Request Client identification
Origin / Access-Control-Allow-Origin Request / response CORS

6. REST's Six Constraints

The original constraints as Fielding laid them out:

  1. Client-Server — separation.
  2. Stateless — the server stores no state between requests. Every request carries the info it needs.
  3. Cacheable — responses indicate whether they are cacheable.
  4. Layered System — intermediate gateways and proxies are allowed.
  5. Uniform Interface — resources, representations, and hypermedia present a uniform interface.
  6. Code-On-Demand (optional) — the server may send code.

Most of what we call "REST APIs" today follow only part of #5 — primarily resource-oriented URLs and HTTP method mapping. Fielding himself wrote "that is not REST" in a frequently-cited piece. In practical terms the name has stuck, and when stricter forms are needed, alternatives like GraphQL, gRPC, or JSON:API come up.

7. HTTP/2 and HTTP/3

  • HTTP/2 (2015) — multiple streams multiplexed over a single TCP connection. Header compression (HPACK). Server push (now effectively deprecated). Binary framing.
  • HTTP/3 (2022) — runs on QUIC, which is UDP-based, instead of TCP. Avoids TCP head-of-line blocking. TLS is integrated into the protocol.

Most modern browsers and CDNs support HTTP/2 and HTTP/3 together. Application code rarely needs to care directly.

8. API Styles Beyond REST

  • GraphQL (Facebook, 2015) — single endpoint, the client specifies which fields it needs. Avoids over-fetching.
  • gRPC (Google, 2016) — Protocol Buffers over HTTP/2. Type-enforced, bidirectional streaming, high performance. Direct calls from browsers are difficult, so gRPC-Web or a gateway is needed.
  • WebSocket (RFC 6455, 2011) — bidirectional persistent connection. Chat, real-time.
  • Server-Sent Events — server → client one-way stream. HTTP-based, so simple.
  • JSON-RPC · XML-RPC — function-call style.

9. Common Shape

curl is the standard tool on both OSes. Built-in on macOS and Linux, and on Windows from 10 1803+:

# GET
curl -i https://httpbin.org/get
curl -i "https://httpbin.org/get?q=hello"

# POST JSON
curl -X POST https://httpbin.org/post \
  -H "Content-Type: application/json" \
  -d '{"name":"lee"}'

# 헤더 포함, 응답 헤더만 보기
curl -I https://example.com

# 인증 헤더
curl -H "Authorization: Bearer TOKEN" https://api.example.com/me

PowerShell also runs the same curl (by default it's an alias of Invoke-WebRequest, but Win10 1803+ ships the real curl.exe alongside). To avoid the distinction, write curl.exe explicitly.

10. Common Pitfalls

fetch not rejecting on 4xx / 5xx — check r.ok or r.status directly.

CORS — when calling another origin's API from the browser, the call is blocked unless the server permits it via Access-Control-Allow-Origin. This is purely a browser policy; the server-side call still happens.

Cache — the difference between Cache-Control: no-cache and no-store. no-cache means "revalidate before use", no-store means "do not store at all".

Redirects — 301 / 308 are permanent, 302 / 307 are temporary. Browsers cache permanent redirects, so once a wrong one is set, undoing it is awkward.

Authentication vs authorization — the difference between 401 and 403 affects user experience and security log analysis.

Closing thoughts

HTTP is a foundation built up over 35 years of method, status code, and header agreements on top of a simple request-response model. "REST APIs" that follow only part of the six constraints have become the de facto standard, with GraphQL and gRPC stepping in for stricter spots. As HTTP/2 and HTTP/3 settle in, the benefits of multiplexing and QUIC arrive automatically. What application developers handle daily comes down to four things: methods, status codes, headers, and REST's resource-oriented URLs.

Next

  • url-anatomy
  • internet-how-it-works

RFC 9110 HTTP Semantics · RFC 9112 HTTP/1.1 · RFC 9113 HTTP/2 · RFC 9114 HTTP/3 · Roy Fielding dissertation (2000) · REST API Tutorial · MDN HTTP · HTTP Cats · curl manual · HTTPie for reference.

More in web-fundamentals

All in this category →
  • Browser DevTools — The First Tool for Debugging
  • How the Internet Works
  • URL Anatomy — Reading the Address Bar
  • JavaScript Basics — The Browser's Dynamic Language
  • CSS — Look and Layout
  • HTML — The Skeleton of a Web Page