API 설계
제가 API를 설계할 때 따르는 RESTful API 설계 원칙입니다.
RESTful API 기본 원칙
HTTP 메서드
각 HTTP 메서드는 명확한 의미를 가집니다:
| 메서드 | 용도 | 멱등성 | 안전성 |
|---|---|---|---|
GET | 리소스 조회 | O | O |
POST | 리소스 생성 | X | X |
PUT | 리소스 전체 수정 | O | X |
PATCH | 리소스 부분 수정 | X | X |
DELETE | 리소스 삭제 (Soft Delete) | O | X |
멱등성: 동일한 요청을 여러 번 보내도 결과가 동일 안전성: 서버 상태를 변경하지 않음
URL 설계 규칙
| |
HTTP 상태 코드
성공 응답 (2xx)
| |
클라이언트 오류 (4xx)
| |
서버 오류 (5xx)
| |
요청/응답 DTO
Request DTO
| |
Response DTO
| |
리스트 응답 (페이징)
| |
에러 응답
표준 에러 응답 형식
| |
검증 오류 처리
| |
비즈니스 오류 처리
| |
API 버전 관리
URL 버전 관리 (권장)
| |
헤더 버전 관리
| |
필터링, 정렬, 검색
필터링
| |
정렬
| |
검색
| |
Validation 계층
Request DTO Validation
| |
Custom Validation
| |
비즈니스 검증 (Service 계층)
| |
보안 (Security)
비밀번호 평문 저장 금지
| |
XSS 방지
| |
CSRF 토큰 사용
| |
JWT 토큰 보안
| |
인증 헤더
| |
Input Sanitization
| |
Rate Limiting
| |
CORS 설정
| |
체크리스트
API 설계 시:
- RESTful 원칙을 따르는가? (명사, 복수형, HTTP 메서드)
- 적절한 HTTP 상태 코드를 사용하는가?
- URL에 버전을 포함하는가? (/api/v1/…)
- Request/Response DTO를 사용하는가? (Domain 직접 노출 금지)
- 일관된 에러 응답 형식을 사용하는가?
Validation:
- Request DTO에 Bean Validation 어노테이션이 있는가?
- Controller에서 @Valid를 사용하는가?
- 비즈니스 검증은 Service 계층에서 수행하는가?
- Custom Validation이 필요한 경우 구현했는가?
- 입력 값 정제(sanitization)를 수행하는가?
보안 (Security):
- SQL Injection 방지를 위해 Prepared Statement를 사용하는가?
- XSS 방지를 위해 HTML 이스케이프 처리를 하는가?
- CSRF 토큰을 사용하는가? (stateful의 경우)
- 비밀번호를 평문으로 저장하지 않는가? (BCrypt 사용)
- JWT 토큰에 강력한 알고리즘을 사용하는가? (HS512 이상)
- HTTPS를 강제하는가?
- 민감정보를 로깅하지 않는가?
- 예외 메시지에 민감정보가 포함되지 않는가?
- CORS가 적절히 설정되어 있는가?
- Rate Limiting이 적용되어 있는가?
인증/인가:
- 인증이 필요한 API에 인증이 적용되어 있는가?
- 역할 기반 접근 제어(RBAC)가 구현되어 있는가?
- Stateless 세션 관리를 사용하는가? (JWT)
- 토큰 만료 시간이 적절한가?
에러 메시지:
- 에러 메시지가 명확한가?
- 일관된 에러 응답 형식을 사용하는가?
- 검증 오류 시 어떤 필드가 문제인지 명시하는가?
- 민감정보가 에러 메시지에 포함되지 않는가?
페이징 및 필터링:
- 리스트 API에 페이징이 적용되어 있는가?
- 페이징 파라미터(page, size)가 명확한가?
- 필터링 파라미터가 명확한가?
- 정렬 옵션이 제공되는가?
- 최대 페이지 크기 제한이 있는가? (예: max 100)