API 설계 playground

1. REST — 리소스 + HTTP 메서드

메서드와 URL 조합으로 어떤 행위를 표현하는지 라이브로 확인. URL 의 마지막이 ID(숫자) 인지 아닌지에 따라 의미가 바뀐다.

메서드 URL

GET /orders/42

→ orders 1개 조회

// REST 의 핵심 — 명사는 URL, 동사는 HTTP 메서드
GET    /orders        // 목록 조회
GET    /orders/42     // 1개 조회
POST   /orders        // 생성
PATCH  /orders/42     // 일부 수정
DELETE /orders/42     // 삭제

2. 상태 코드 — 대역별 의미

코드 버튼을 클릭하면 의미와 대응 방법이 표시됩니다. 색 = 대역 (초록 2xx / 주황 4xx / 빨강 5xx).

위의 코드를 클릭해보세요.

3. 멱등성 — 같은 요청 N 번 시뮬레이션

메서드를 고른 다음 "재시도 한 번 더" 를 눌러보세요. POST 는 호출마다 새 주문이 쌓이고, 멱등 메서드는 결과가 그대로입니다.

메서드

요청 횟수: 0

서버 상태: orders = []

// POST 는 호출마다 새 리소스 생성 → 결제 두 번 사고 위험
// 해결: Idempotency-Key 헤더로 같은 요청임을 알려줌
POST /orders
Idempotency-Key: a1b2c3-...
{ "amount": 5000 }

4. 페이지네이션 — Offset vs Cursor

"데이터 1개 추가" 를 누르면 새 주문이 맨 위에 추가됩니다. Offset 은 페이지가 밀려서 중복이 생기고, Cursor 는 기준점이 고정되어 안정적입니다.

Offset (페이지 2, 3개씩)

정상

Cursor (1페이지 마지막 ID 이후 3개)

기준점 고정 — 안정

// Offset — 페이지 N = 앞 (N-1)*size 개 건너뜀
GET /orders?limit=3&offset=3

// Cursor — 직전 페이지의 마지막 ID 이후로 N 개
GET /orders?limit=3&cursor=order_42_2026-06-19T12:00:00Z

5. 인증 (401) vs 인가 (403)

토큰 상태와 권한 조합에 따라 어떤 상태 코드가 나오는지 직접 확인.

토큰 요청 리소스 소유자 내 역할

결과: 값을 선택하세요.

// 인증 (Authentication) — "누구?"
// → 토큰 없거나 잘못됨 → 401 Unauthorized

// 인가 (Authorization) — "뭘 할 수 있어?"
// → 토큰 유효하지만 권한 없음 → 403 Forbidden

6. CORS — 다른 출처일 때 브라우저의 판단

요청 출처와 서버가 허용한 출처를 비교해서 브라우저가 응답을 통과시킬지 결정합니다. * 면 모든 출처 허용.

요청 출처 서버 Allow-Origin

결과: —

// 서버 응답 헤더로 허용 출처 알림
HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://my-app.com

// 브라우저: 응답은 도착했지만 출처 안 맞으면 JS 에 전달 X