HTTP 와 REST — 클라이언트와 서버의 약속

브라우저가 서버에 무엇을 요청하고, 서버가 어떻게 답하는가. 이 단순한 질문 위에 웹의 거의 모든 것이 얹혀 있습니다. 이 글은 HTTP 의 출자 · 메서드와 상태 코드 · 헤더 · REST 의 원래 의미 · HTTP/2 · 3 의 변화.

1. HTTP 와 REST 에 대한 이야기

HTTP 는 HyperText Transfer Protocol 의 줄임말. Tim Berners-Lee 가 1989 년 CERN 에서 제안했고, 1991 년의 0.9 버전 (한 줄 요청 · HTML 만) 을 거쳐 1996 년 RFC 1945 (HTTP/1.0), 1997 년 RFC 2068 (HTTP/1.1, 1999 년 RFC 2616 으로 개정) 으로 표준화. 2015 년 RFC 7540 의 HTTP/2, 2022 년 RFC 9114 의 HTTP/3 이 차례로.

REST 는 Representational State Transfer 의 줄임말. 2000 년 Roy Fielding 의 박사 논문 "Architectural Styles and the Design of Network-based Software Architectures" 에서 정의. HTTP 자체와는 다른 층의 개념으로, "웹의 여러 좋은 성질을 그대로 따르는 API 디자인 스타일" 정도가 가까움.

2. 요청-응답 모델

클라이언트가 요청을 보내고 서버가 응답을 돌려주는 구조. HTTP/1.1 의 keep-alive 는 같은 연결을 재사용하지만 직렬 처리는 같음. HTTP/2 부터 한 연결에 여러 요청이 동시에 흐를 수 있음.

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. 메서드

메서드	의도	멱등	요청 본문
GET	자원 조회	yes	일반적으로 없음
POST	자원 생성 · 범용 작업	no	있음
PUT	자원 전체 교체	yes	있음
PATCH	자원 부분 수정	일반적으로 no	있음
DELETE	자원 삭제	yes	일반적으로 없음
HEAD	GET 의 헤더만	yes	없음
OPTIONS	메서드 · CORS 사전요청	yes	없음

"멱등 (idempotent)" 은 같은 요청을 여러 번 보내도 결과가 같다는 뜻. 네트워크 재시도 정책이 이 성질에 의존.

4. 상태 코드

3 자리 숫자. 첫 자리로 카테고리:

카테고리	의미	자주 만나는 코드
1xx	정보	100 Continue · 101 Switching Protocols
2xx	성공	200 OK · 201 Created · 204 No Content
3xx	리다이렉트	301 Moved Permanently · 302 Found · 304 Not Modified · 307 Temporary Redirect · 308 Permanent Redirect
4xx	클라이언트 오류	400 Bad Request · 401 Unauthorized · 403 Forbidden · 404 Not Found · 409 Conflict · 422 Unprocessable Entity · 429 Too Many Requests
5xx	서버 오류	500 Internal Server Error · 502 Bad Gateway · 503 Service Unavailable · 504 Gateway Timeout

401 과 403 의 차이가 자주 헷갈림. 401 은 "당신이 누구인지 모르겠다 (인증 필요)", 403 은 "당신을 알지만 권한이 없다".

5. 헤더

헤더	자리	쓰임
Content-Type	양쪽	본문 형식 (application/json · text/html · multipart/form-data)
Accept	요청	클라이언트가 받고 싶은 형식
Authorization	요청	인증 (Bearer ... · Basic ...)
Cookie / Set-Cookie	요청 / 응답	쿠키
Cache-Control	양쪽	캐시 정책 (no-store · max-age=3600)
ETag / If-None-Match	응답 / 요청	조건부 요청 (변경 없으면 304)
Location	응답	리다이렉트 대상
User-Agent	요청	클라이언트 식별
Origin / Access-Control-Allow-Origin	요청 / 응답	CORS

6. REST 의 6 제약

Fielding 이 정리한 원래 제약:

1. Client-Server — 분리.
2. Stateless — 서버는 요청 사이의 상태를 저장하지 않음. 필요한 정보는 매번 요청에.
3. Cacheable — 응답이 캐시 가능 여부를 명시.
4. Layered System — 중간 게이트웨이 · 프록시가 있어도 됨.
5. Uniform Interface — 자원 · 표현 · 하이퍼미디어가 일관된 인터페이스로.
6. Code-On-Demand (선택) — 서버가 코드를 보낼 수도 있음.

오늘 "REST API" 라 불리는 대부분은 5 번의 일부, 특히 자원 중심 URL · HTTP 메서드 매핑 정도만 따름. Fielding 본인이 "그건 REST 가 아니다" 라고 한 글이 자주 인용. 실용 관점에서는 이름이 굳어졌고, 더 엄격한 형태가 필요할 때 GraphQL · gRPC · JSON:API 같은 대안이 거론됩니다.

7. HTTP/2 와 HTTP/3

• HTTP/2 (2015) — 단일 TCP 연결 위에서 여러 스트림 멀티플렉싱. 헤더 압축 (HPACK). 서버 푸시 (현재 사실상 deprecated). 바이너리 프레이밍.
• HTTP/3 (2022) — TCP 대신 UDP 기반의 QUIC 위에서 동작. TCP head-of-line blocking 을 피함. TLS 가 프로토콜에 통합.

대부분의 모던 브라우저 · CDN 이 HTTP/2 와 HTTP/3 을 함께 지원. 애플리케이션 코드가 직접 신경 쓸 일은 적음.

8. REST 외의 API 스타일

• GraphQL (Facebook, 2015) — 단일 엔드포인트, 클라이언트가 필요한 필드를 명시. over-fetching 회피.
• gRPC (Google, 2016) — HTTP/2 위 Protocol Buffers. 타입 강제 · 양방향 스트리밍 · 고성능. 브라우저 직접 호출이 어려워 gRPC-Web 또는 게이트웨이 필요.
• WebSocket (RFC 6455, 2011) — 양방향 영구 연결. 채팅 · 실시간.
• Server-Sent Events — 서버 → 클라이언트 단방향 스트림. HTTP 기반이라 단순.
• JSON-RPC · XML-RPC — 함수 호출 형태.

9. 자주 쓰는 모양

curl 은 양쪽 OS 에 표준 도구. macOS · Linux 는 기본 탑재, Windows 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 도 동일한 curl 이 동작 (기본은 Invoke-WebRequest 의 별칭이지만 Win10 1803+ 부터 진짜 curl.exe 가 함께 깔림). 차이를 피하려면 curl.exe 로 명시.

10. 자주 걸리는 자리

fetch 가 4xx / 5xx 응답에 reject 하지 않음 — r.ok 또는 r.status 를 직접 확인.

CORS — 다른 출처 (origin) 의 API 를 브라우저에서 호출할 때 서버가 Access-Control-Allow-Origin 헤더로 허락하지 않으면 막힘. 브라우저 정책일 뿐 서버 호출 자체는 일어남.

캐시 — Cache-Control: no-cache 와 no-store 의 차이. no-cache 는 "재검증 후 사용", no-store 는 "저장 자체 금지".

리다이렉트 — 301 / 308 은 영구, 302 / 307 은 임시. 영구 리다이렉트는 브라우저가 캐싱하므로 한 번 잘못 박히면 되돌리기 까다로움.

인증 vs 인가 — 401 과 403 의 차이가 사용자 경험과 보안 로그 분석에 영향.

하고픈 말

HTTP 는 단순한 요청-응답 모델 위에 35 년 동안 메서드 · 상태 코드 · 헤더의 약속이 쌓인 토대. REST 의 6 제약 중 일부만 따르는 "REST API" 가 사실상 표준이 됐고, 더 엄격한 자리에 GraphQL · gRPC. HTTP/2 · 3 이 자리잡으면서 멀티플렉싱 · QUIC 의 이점은 자동으로 따라옴. 애플리케이션 개발자가 자주 다루는 것은 결국 메서드 · 상태 코드 · 헤더 · REST 의 자원 중심 URL 넷.

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 박사논문 (2000) · REST API Tutorial · MDN HTTP · HTTP Cats · curl 매뉴얼 · HTTPie 를 참고합니다.