HTTP와 REST Quest

Tracks

1. 01🧱기초 — HTTP가 실제로 작동하는 방식

   0/7 lessons

   우편 비유부터 상태 코드 계열까지, 실제 HTTP 통신을 읽는 법

   HTTP를 웹의 우편 제도라고 생각하면 출발이 쉬워져. 먼저 요청과 응답의 구조를 해부하고, 그 아래에서 TCP와 TLS가 맡는 일을 살펴보자. 이어서 HTTP/0.9부터 HTTP/3까지의 변화, 메서드의 의미, 헤더의 역할, 상태 코드 계열을 차례로 익혀. 일곱 과를 마치면 브라우저 개발자 도구나 curl에 나타난 HTTP 통신을 차분하게 읽을 수 있을 거야.

   Lesson list (7)

   • 01
     웹의 우편 제도 — HTTP가 하는 일~10 min · foundations, intuition, postal-service, stateless
   • 02
     요청과 응답 해부하기 — 네 부분으로 읽는 법~11 min · foundations, anatomy, request, response
   • 03
     HTTP 아래의 TCP와 TLS — 연결부터 암호화까지~11 min · foundations, tcp, tls, https, transport
   • 04
     HTTP 버전의 진화 — 0.9에서 3까지~11 min · foundations, http1, http2, http3, quic, multiplexing
   • 05
     HTTP 메서드 — 의도에 맞는 동사를 고르는 법~10 min · foundations, methods, verbs, overview
   • 06
     HTTP 헤더 — 역할별로 묶어 읽기~11 min · foundations, headers, metadata, taxonomy
   • 07
     상태 코드 계열 — 첫 숫자로 응답 읽기~12 min · foundations, status-codes, polymorphic, dispatch

   ✓퀴즈 · 6 문제→

2. 02🎯HTTP 의미론 — 메서드와 상태 코드의 계약

   0/6 lessons

   안전성·멱등성·캐시 가능성부터 콘텐츠 협상, 조건부 요청, 버전 관리까지

   HTTP의 메서드와 상태 코드는 단순한 이름이 아니라 동작에 관한 계약이야. 안전성과 멱등성이 재시도와 캐시에 어떤 영향을 주는지 살펴보고, 상황에 맞는 상태 코드를 고르는 기준을 익힌다. Accept와 Content-Type으로 표현을 협상하는 법, ETag와 조건부 헤더로 캐시를 검증하고 동시 수정 충돌을 막는 법도 다뤄. 마지막에는 버전 관리 전략을 비교하고, 메서드 결정표로 판단 기준을 하나로 정리해.

   Lesson list (6)

   • 01
     안전성과 멱등성 — 어떤 요청을 다시 보내도 되는가~12 min · semantics, idempotency, safety, cacheability
   • 02
     상태 코드 선택 — 상황을 정확히 설명하는 응답~11 min · semantics, status-codes, dispatch, refinement
   • 03
     콘텐츠 협상 — 하나의 리소스, 여러 표현~11 min · semantics, content-negotiation, accept, vary
   • 04
     조건부 요청 — 캐시를 검증하고 덮어쓰기를 막는 법~12 min · semantics, conditional-requests, etag, if-match, 304
   • 05
     API 버전 관리 — 기존 계약을 지키며 진화하기~11 min · semantics, versioning, evolution, deprecation
   • 06
     HTTP 메서드 결정표 — 작업의 의미에서 메서드까지~10 min · semantics, methods, decision, synthesis

   ✓퀴즈 · 6 문제→

3. 03🏛️REST 설계 — 리소스와 표현을 중심에 놓기

   0/7 lessons

   리소스, URI, HATEOAS, 페이지 나누기, 오류 계약

   REST를 메서드 이름의 모음이 아니라 리소스를 중심에 둔 설계 방식으로 배워. 리소스 지향 설계와 RPC의 경계를 살피고, 오래 버티는 URI를 설계해. HATEOAS는 Fielding이 제시한 원형과 운영 현장의 선택을 이어서 읽으며 균형 있게 판단해. 페이지 나누기, 필터링과 정렬, 필요한 필드만 고르는 방법, 일관된 오류 응답까지 차근차근 다뤄.

   Lesson list (7)

   • 01
     리소스와 RPC — 명사와 동작이 갈리는 지점~11 min · rest-design, resources-vs-rpc, mental-model
   • 02
     URI 설계 — 오래 버티는 주소를 만드는 법~10 min · rest-design, uri-design, naming
   • 03
     HATEOAS — Fielding의 원형을 정확히 읽기~12 min · rest-design, hateoas, fielding, pure
   • 04
     HATEOAS의 현실 — 원칙과 운영의 간격~11 min · rest-design, hateoas, honest, rpc-over-http
   • 05
     페이지 나누기 — 오프셋과 커서의 선택~11 min · rest-design, pagination, cursor, offset
   • 06
     필터·정렬·필드 선택 — 목록 API를 다듬는 계약~10 min · rest-design, filtering, sorting, fieldsets
   • 07
     구조화된 오류 응답 — 실패까지 계약으로 만들기~10 min · rest-design, errors, error-envelope, rfc7807

   ✓퀴즈 · 6 문제→

4. 04🛡️인증과 보안 — 자격 증명부터 브라우저 경계까지

   0/6 lessons

   Basic과 Bearer부터 JWT, OAuth 2.0, CORS, 요청 제한까지

   자격 증명을 HTTP 요청에 어떻게 싣고, 언제까지 신뢰하며, 어떻게 폐기할지 배워. Basic과 Bearer의 차이에서 출발해 API 키와 토큰의 수명 주기, JWT와 갱신 토큰, PKCE를 적용한 OAuth 2.0 흐름을 차례로 살펴봐. 서버가 선언한 정책을 브라우저가 CORS로 집행하는 방식과 429 응답을 활용한 요청 제한도 함께 익혀.

   Lesson list (6)

   • 01
     Basic과 Bearer — 자격 증명을 싣는 두 가지 방식~10 min · auth-security, basic, bearer, authorization
   • 02
     API 키와 토큰 — 이름보다 수명과 권한을 봐~10 min · auth-security, api-keys, tokens, rotation
   • 03
     JWT와 갱신 토큰 — 짧은 접근 권한, 오래가는 세션~12 min · auth-security, jwt, claims, refresh
   • 04
     OAuth 2.0과 PKCE — 비밀값을 숨길 수 없는 클라이언트~12 min · auth-security, oauth2, pkce, authorization-code
   • 05
     CORS 제대로 이해하기 — 서버가 선언하고 브라우저가 집행해~12 min · auth-security, cors, preflight, browser
   • 06
     요청 제한 — 429로 공정한 사용량 제어하기~10 min · auth-security, rate-limiting, 429, retry-after

   ✓퀴즈 · 6 문제→

5. 05⚡캐시와 성능 — 가장 빠른 전송은 다시 보내지 않는 것

   0/5 lessons

   Cache-Control, 조건부 GET, CDN, 압축, HTTP/2

   HTTP에는 API 설계에서 놓치기 쉬운 정교한 캐시 프로토콜이 있어. Cache-Control로 서버와 캐시가 재사용 규칙을 정하고, 조건부 GET으로 본문 전송을 통째로 생략하는 법을 배워. 브라우저·CDN·원본 서버의 캐시가 어떻게 이어지는지 살펴본 뒤, gzip·Brotli·zstd 압축과 연결 재사용이 비용을 어떻게 줄이는지도 확인해. 마지막에는 HTTP/2 다중화가 HTTP/1.1 시대의 클라이언트 설계 원칙을 어디까지 바꿨고, 무엇은 여전히 한계로 남는지 정리해.

   Lesson list (5)

   • 01
     HTTP 캐시 헤더 — 저장과 재사용을 정하는 계약~11 min · caching-perf, cache-control, etag, last-modified
   • 02
     조건부 GET — 304로 본문 전송 생략하기~10 min · caching-perf, conditional-get, 304, etag-revisited
   • 03
     CDN 계층 — 브라우저에서 원본 서버까지 이어지는 캐시~10 min · caching-perf, cdn, edge, origin
   • 04
     압축과 연결 재사용 — 바이트와 왕복 줄이기~10 min · caching-perf, compression, gzip, brotli, keep-alive
   • 05
     HTTP/2 다중화 — 요청 비용의 계산법이 달라진 이유~10 min · caching-perf, http2, multiplexing, client-design

   ✓퀴즈 · 5 문제→

6. 06🌊스트리밍과 비동기 — 한 번의 응답 너머로

   0/5 lessons

   폴링, SSE, 청크 전송, WebSocket, 웹훅, 202 Accepted

   요청 하나와 응답 하나만으로는 오래 걸리거나 계속 이어지는 작업을 온전히 다루기 어려워. 폴링과 롱 폴링에서 출발해 SSE와 청크 전송이 서버의 연속 출력을 어떻게 전달하는지 살펴봐. 양쪽이 서로 독립적으로 메시지를 보내야 할 때 WebSocket을 선택하는 기준도 세우고, 마지막에는 웹훅으로 호출 방향을 뒤집는 방법과 202 Accepted로 비동기 작업의 상태를 공개하는 패턴을 익혀.

   Lesson list (5)

   • 01
     폴링에서 롱 폴링까지 — 기다림의 비용~10 min · streaming-async, polling, long-polling
   • 02
     SSE — 서버에서 흘러오는 단방향 이벤트~11 min · streaming-async, sse, event-stream, ai-streaming
   • 03
     청크 전송 — 길이를 미리 모르는 HTTP/1.1 본문~9 min · streaming-async, chunked-transfer, http1
   • 04
     REST와 WebSocket의 경계~10 min · streaming-async, websocket, rest-vs-ws
   • 05
     웹훅과 202 Accepted — 호출 방향을 뒤집고 작업을 분리하기~10 min · streaming-async, webhooks, 202, async

   ✓퀴즈 · 5 문제→

7. 07🚀운영 — 프로토콜을 실제 서비스로 만들기

   0/6 lessons

   관측 가능성, curl, OpenAPI, 복원력, API 수명 주기

   HTTP 프로토콜을 이해하는 것과 API를 안정적으로 운영하는 것은 별개의 일이야. 상관관계 ID로 여러 서비스에 흩어진 요청의 흔적을 연결하고, curl로 실제 송수신 내용을 확인해. HTTPie·Postman·Insomnia가 각각 언제 유용한지 구분하고, OpenAPI와 JSON Schema로 기계가 읽을 수 있는 계약을 만들어. 안전한 재시도와 백오프, 회로 차단기로 부분 장애의 확산을 막은 다음, API 게이트웨이와 체계적인 지원 중단 절차로 장기 운영까지 완성해.

   Lesson list (6)

   • 01
     관측 가능성과 상관관계 ID — 분산 요청의 흔적 잇기~10 min · production, observability, correlation-id, tracing
   • 02
     curl — 실제 HTTP 교환을 확인하는 도구~10 min · production, curl, debugging
   • 03
     HTTPie·Postman·Insomnia — 목적에 맞는 API 도구 고르기~9 min · production, httpie, postman, insomnia, gui-clients
   • 04
     OpenAPI와 JSON Schema — 기계가 읽을 수 있는 API 계약~11 min · production, openapi, json-schema, spec
   • 05
     운영 클라이언트 설계 — 재시도·백오프·회로 차단기~11 min · production, retry, backoff, circuit-breaker
   • 06
     API 게이트웨이와 버전 수명 주기 관리~10 min · production, api-gateway, versioning, deprecation

   ✓퀴즈 · 6 문제→

8. 08🎓에필로그 — cwkPippa에서 다음 단계로

   0/4 lessons

   운영 코드를 읽고, 적합한 방식을 선택하고, 직접 구현하기

   앞선 일곱 트랙에서 익힌 개념을 실제 코드와 설계 판단으로 다지는 네 개의 마무리 과다. 먼저 cwkPippa 백엔드에서 REST, SSE, WebSocket이 서로 다른 통신 형태를 어떻게 나누어 맡는지 살펴본다. 이어서 gRPC, GraphQL, RPC가 REST보다 적합한 조건을 구분하고, 지금까지 배운 HTTP 계약을 한데 모은 작은 CRUD 서비스를 직접 설계한다. 마지막으로 이 퀘스트가 의도적으로 다루지 않은 주제와 현실적인 후속 학습 경로를 정리한다.

   Lesson list (4)

   • 01
     cwkPippa에서 REST 읽기 — 실제 코드베이스 탐색~10 min · epilogue, cwkpippa, synthesis, self-reference
   • 02
     REST가 아닌 선택 — gRPC, GraphQL, RPC~10 min · epilogue, grpc, graphql, alternatives
   • 03
     직접 만드는 CRUD — 모든 개념을 하나의 서비스에~12 min · epilogue, crud, synthesis, capstone
   • 04
     다음 단계 — 이 퀘스트 이후의 로드맵~8 min · epilogue, roadmap, next-steps

   ✓퀴즈 · 4 문제→