REST API에 대해

1. REST API의 개념

• REST(Representational State Transfer)는 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하는 아키텍처 스타일
• 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 것이 핵심
• HTTP URI를 통해 자원을 명시하고, HTTP Method(GET, POST, PUT, DELETE)를 통해 해당 자원에 대한 CRUD Operation을 적용

2. REST 6가지 기본 원칙

• Client-Server 구조: 서버와 클라이언트의 역할이 명확히 구분됨
• Stateless: 각 요청은 독립적이며, 서버는 클라이언트의 상태를 저장하지 않음
• Cacheable: HTTP의 캐싱 기능을 적용할 수 있음
• Uniform Interface: URI로 지정한 리소스에 대한 조작이 통일되고 한정적인 인터페이스로 수행
• Layered System: 계층형 구조로 구성 가능
• Code on Demand(선택): 클라이언트는 서버로부터 스크립트를 받아서 실행할 수 있음

3. HTTP Methods의 역할

• GET: 리소스 조회
• POST: 리소스 생성
• PUT: 리소스 수정
• DELETE: 리소스 삭제
• PATCH: 리소스 부분 수정

4. REST API 설계 규칙

• URI는 자원을 표현해야 하며, 동사보다는 명사를 사용
  예: /members (O), /getMember (X)
• 자원에 대한 행위는 HTTP Method로 표현
• URI 경로는 계층 관계를 표현
  예: /members/1/orders
• URI는 소문자로 작성
• 단어 구분은 하이픈(-) 사용 권장
  예: /order-items

5. REST API 응답 상태 코드

• 200: 요청 성공
• 201: 리소스 생성 성공
• 400: 잘못된 요청
• 401: 인증 실패
• 403: 권한 없음
• 404: 리소스를 찾을 수 없음
• 500: 서버 내부 오류

6. 장점

• HTTP 프로토콜의 인프라를 그대로 사용하므로 별도의 인프라 구축이 필요 없음
• HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용 가능
• 서버와 클라이언트의 역할을 명확하게 분리

7. 단점

• 표준이 존재하지 않아 정의가 필요
• HTTP Method 형태가 제한적
• 구형 브라우저에서 PUT, DELETE를 사용하지 못할 수 있음

실제 REST API 예시:

# 회원 목록 조회
GET /api/members

# 특정 회원 조회
GET /api/members/{id}

# 새로운 회원 생성
POST /api/members

# 회원 정보 수정
PUT /api/members/{id}

# 회원 삭제
DELETE /api/members/{id}

# 회원의 주문 목록 조회
GET /api/members/{id}/orders

REST API를 설계할 때는 일관성 있는 URI 설계와 적절한 HTTP Method 사용이 중요함.
또한 API 문서화와 버전 관리도 고려해야 할 중요한 요소.