REST API 정리

1. REST의 탄생

• REST(Representational State Transfer)는 2000년 로이 필딩의 박사 논문에서 처음 소개됨
• HTTP 설계의 장점을 최대한 활용할 수 있는 아키텍처 스타일

---

2. REST 구성 요소

1. 자원(Resource) → URI로 표현
2. 행위(Verb) → HTTP Method (GET, POST, PUT, DELETE)
3. 표현(Representation) → JSON, XML 등으로 리소스를 주고받는 방식

---

3. REST의 특징

1. Uniform Interface

   • 통일된 인터페이스로 리소스를 다룸

2. Stateless (무상태성)

   • 서버는 상태 저장 안 함 → 요청에 필요한 정보는 클라이언트가 포함

3. Cacheable (캐시 가능)

   • HTTP 캐시 기능 활용 가능 (ETag, Last-Modified 등)

4. Self-descriptiveness (자체 표현 구조)

   • 메시지만 보고도 무슨 요청인지 이해 가능

5. Client-Server 구조

   • 서버는 API 제공, 클라이언트는 인증·세션 관리

6. 계층형 구조

   • 프록시, 게이트웨이, 보안, 로드밸런싱 등 중간 계층 추가 가능

---

4. REST API 디자인 가이드

핵심 규칙

1. URI는 자원을 표현 (명사 사용, 동사 지양)
2. 행위는 HTTP Method로 표현

예시:

• 잘못된 URI

  GET /members/delete/1

• 올바른 URI

  DELETE /members/1

HTTP Method와 CRUD

• POST → 리소스 생성
• GET → 리소스 조회
• PUT → 리소스 수정
• DELETE → 리소스 삭제

---

URI 설계 원칙

1. 슬래시(/)는 계층 관계 표현

   • /animals/mammals/whales

2. 마지막에 슬래시 / 붙이지 않음

3. 하이픈(-)은 가독성 ↑, 밑줄(_)은 사용하지 않음

4. 소문자 사용 (대소문자 구분됨)

5. 확장자(.jpg, .json 등) 넣지 않음 → Accept 헤더 활용

6. 리소스 간 관계 표현

   • /users/{userId}/devices
   • /users/{userId}/likes/devices

---

Collection & Document

• Collection: 리소스의 집합 (복수형 사용)
• Document: 개별 리소스

예시:

• /sports → 컬렉션
• /sports/soccer → 도큐먼트
• /sports/soccer/players/13 → 컬렉션 + 도큐먼트 조합

---

5. HTTP 응답 상태 코드

상태 코드	의미
200 OK	요청 정상 처리
201 Created	리소스 생성 성공 (POST)
400 Bad Request	잘못된 요청
401 Unauthorized	인증 실패
403 Forbidden	접근 금지 (리소스 존재하지만 거부)
404 Not Found	리소스 없음
405 Method Not Allowed	허용되지 않은 메서드
301 Moved Permanently	리소스 URI 변경 (Location 헤더 포함)
500 Internal Server Error	서버 오류

• REST API는 명확한 표준은 없지만, 합리적인 가이드라인이 있음
• URI = 자원, HTTP Method = 행위
• 설계 시 가독성과 일관성을 유지하는 것이 핵심