RESTful(Representational State Transfer) 아키텍처 스타일은 클라이언트와 서버 간의 통신을 설계하는 방식입니다. RESTful은 특정한 기술이나 프로토콜이 아니라 설계 원칙과 제약 조건을 따르는 아키텍처 스타일입니다. 모든 API가 RESTful은 아니며, RESTful로 간주되기 위해서는 몇 가지 설계 원칙을 따라야 합니다.
### REST의 주요 설계 원칙
1. **클라이언트-서버 구조 (Client-Server Architecture)**:
- 클라이언트와 서버가 서로 독립적으로 동작하며, 클라이언트는 사용자 인터페이스를 담당하고, 서버는 데이터 저장 및 비즈니스 로직을 담당합니다.
2. **스테이트리스 (Stateless)**:
- 서버는 각 요청을 독립적으로 처리하며, 요청 간에 상태를 저장하지 않습니다. 클라이언트는 모든 필요한 정보를 요청에 포함시켜야 합니다.
3. **캐시 가능 (Cacheable)**:
- 응답은 캐시 가능해야 하며, HTTP 헤더를 통해 응답이 캐시 가능한지 여부를 명시해야 합니다. 이를 통해 성능을 향상시키고 서버 부하를 줄일 수 있습니다.
4. **계층화 시스템 (Layered System)**:
- 클라이언트는 중간 서버(예: 로드 밸런서, 프록시 서버)를 통해 간접적으로 서버와 통신할 수 있습니다. 이를 통해 보안, 로드 밸런싱, 성능 향상을 도모할 수 있습니다.
5. **코드 온 디맨드 (Code on Demand) (선택 사항)**:
- 서버는 클라이언트에 실행 가능한 코드를 전송할 수 있습니다. 예를 들어, 자바스크립트 코드 등을 클라이언트에 전송하여 실행할 수 있습니다.
6. **통합 인터페이스 (Uniform Interface)**:
- API는 일관된 인터페이스를 제공해야 합니다. 이는 리소스 식별, 리소스 조작, 표현 상태 전이 등을 포함합니다.
### RESTful API 설계의 주요 요소
- **리소스 (Resources)**: URL을 통해 식별되는 개체입니다.
- 예: `/users`, `/posts/1/comments`
- **HTTP 메서드**: 리소스에 대한 CRUD 작업을 정의합니다.
- `GET`: 리소스 조회
- `POST`: 리소스 생성
- `PUT`: 리소스 전체 업데이트
- `PATCH`: 리소스 부분 업데이트
- `DELETE`: 리소스 삭제
- **HTTP 상태 코드**: 응답의 결과를 나타냅니다.
- `200 OK`: 성공
- `201 Created`: 생성됨
- `204 No Content`: 내용 없음
- `400 Bad Request`: 잘못된 요청
- `404 Not Found`: 리소스 없음
- `500 Internal Server Error`: 서버 오류
- **HATEOAS (Hypermedia As The Engine Of Application State)**: 클라이언트가 응답 내의 링크를 통해 다음 작업을 발견할 수 있도록 합니다.
### RESTful이 아닌 예제
단순히 HTTP를 사용한다고 해서 RESTful이 되는 것은 아닙니다. 다음은 RESTful이 아닌 예제입니다:
- **상태 유지 (Stateful) 세션 사용**:
- 서버가 세션 상태를 유지하고, 클라이언트가 이전 요청과 관련된 정보를 보내지 않는 경우.
- **일관되지 않은 URL 구조**:
- 리소스가 아닌 동사를 사용하여 URL을 설계하는 경우.
- 예: `/getUserData`, `/updateUser`
- **적절하지 않은 HTTP 메서드 사용**:
- 데이터를 조회하는 데 `POST`를 사용하는 경우.
### 결론
RESTful API는 설계 원칙과 제약 조건을 준수해야 하며, 이를 통해 클라이언트와 서버 간의 통신을 표준화하고 효율적으로 만들 수 있습니다. 모든 API가 RESTful은 아니며, RESTful로 간주되기 위해서는 특정한 설계 원칙을 따라야 합니다. 따라서, HTTP를 사용한다고 해서 자동으로 RESTful이 되는 것은 아닙니다. RESTful 원칙을 잘 이해하고 적용하는 것이 중요합니다.
CS