1. REST API란?
REST는 HTTP 프로토콜의 장점을 그대로 활용하기 위해 제안된 아키텍처 스타일입니다. 자원을 명시하고, 해당 자원에 대한 행위를 HTTP 메서드로 정의하여 전달하는 방식입니다.
REST의 3대 구성 요소
- 자원 : URI (예:
/users,/posts/1) - 행위 : HTTP Method (
GET,POST,PUT,PATCH,DELETE) - 표현 : Client와 Server가 주고받는 데이터 형태 (
JSON,XML)
2. REST의 6가지 아키텍처 제약 조건
RESTful한 API로 인정받기 위해 준수해야 하는 원칙입니다.
- 클라이언트와 서버 : UI를 담당하는 클라이언트와 비즈니스 로직/데이터를 처리하는 서버를 분리하여 서로 간의 의존성을 줄입니다.
- 무상태성 : 서버는 클라이언트의 상태를 저장하지 않습니다. 각 요청은 필요한 모든 정보를 포함하여 독립적으로 처리됩니다.
- 캐시 가능성 : HTTP의 캐싱 기능을 활용할 수 있어야 하며, 응답에
Cache-Control등을 명시하여 성능을 최적화할 수 있습니다. - 일관된 인터페이스 : URI로 자원이 식별되어야 하며, 자원의 조작은 표준화된 HTTP 방식을 통해 이루어져야 합니다.
- 계층화 시스템 : 클라이언트는 서버의 내부 구조를 알 필요 없이 엔드포인트와만 통신합니다.
- 선택 사항 : 서버가 클라이언트에 실행 가능한 코드를 보낼 수 있습니다.
3. HTTP 메서드와 멱등성
멱등성이란 "동일한 요청을 여러 번 보내도 서버의 상태 및 결과가 항상 동일한 특성"을 의미합니다.
| HTTP Method | 역할 | 변경되지 않음 | 멱등성 |
| GET | 자원 조회 | O | O |
| POST | 새로운 자원 생성 | X | X |
| PUT | 자원 전체 수정 | X | O |
| PATCH | 자원 일부 수정 | X | X |
| DELETE | 자원 삭제 | X | O |
4. RESTful URI 설계 규칙
- 동사 대신 명사를 사용하기
- 소문자를 사용하고 언더바(
_) 대신 하이픈(-) 활용하기 - 마지막에 슬래시(
/)를 포함하지 않기 - 자원 간의 관계를 계층 구조로 표현하기
- 파일 확장자는 URI에 포함하지 않기
5. HTTP 상태 코드
| 구분 | 코드 및 설명 |
| 2xx (성공) |
200 OK (조회/수정 성공), 201 Created (생성 성공), 204 No Content (삭제 성공)
|
| 4xx (클라이언트 에러) |
400 Bad Request (잘못된 요청), 401 Unauthorized (인증 필요), 403 Forbidden (권한 없음), 404 Not Found (자원 없음)
|
| 5xx (서버 에러) |
500 Internal Server Error (서버 내부 로직 오류), 503 Service Unavailable (서버 점검/과부하)
|