REST Architecture
REST는 HTTP API의 URL 표기법이 아니라, 분산 시스템 인터페이스를 위한 아키텍처 스타일이다. 클라이언트는 자원 자체가 아닌 자원의 표현을 주고받고, HTTP 메서드로 그 표현에 대한 행위를 표현한다.[1]
자원·표현·행위
- Resource: 문서, 이미지, 서비스처럼 이름으로 식별 가능한 대상이며 URI로 구분한다.[1:1]
- Representation: 특정 시점의 자원 상태를 전송한 형태다. JSON·XML과
Content-Type이 대표적인 표현 수단이다.[1:2] - Verb: HTTP method로 표현하는 자원에 대한 조회·변경 행위다.[1:3]
제약 조건을 설계 기준으로 쓰기
| 제약 | API 설계에서 확인할 점 |
|---|---|
| Client-Server | UI와 서버 책임이 독립적으로 바뀔 수 있는가 |
| Stateless | 각 요청이 필요한 상태 정보를 포함하는가 |
| Cacheable | 응답의 캐시 가능 여부를 명시할 수 있는가 |
| Layered System | 중간 계층이 있어도 클라이언트가 서버 구조에 의존하지 않는가 |
| Uniform Interface | URI, 표현, 메시지 의미가 일관적인가 |
REST의 제약은 client-server, stateless, cacheable, layered system, uniform interface이며, code-on-demand는 선택 제약이다.[1:4]
Uniform Interface의 네 기준
- URI로 자원을 식별한다.
- 클라이언트는 표현과 메타데이터를 통해 자원을 조작한다.
- 메시지는
Content-Type, HTTP method처럼 처리에 필요한 정보를 스스로 담는다. - 응답의 하이퍼미디어 링크(HATEOAS)는 다음 상태 전이를 안내할 수 있다.[1:5]
성숙도 모델을 체크리스트로 읽기(해석)
Richardson 성숙도 모델은 Level 0(POX), Level 1(Resource), Level 2(HTTP verb), Level 3(Hypermedia control)로 API를 구분한다.[1:6] 원문은 대부분의 상용 "REST API"가 Level 2에 해당하고, Level 3에 도달해야 진정한 RESTful API라고 본다.[1:7] 다만 Level 3 달성 여부보다, 클라이언트 요구와 운영 비용에 맞게 자원 식별·메서드 의미·오류 표현을 일관되게 만드는 편이 실무적 기준이라는 것은 원문과 다른 이 page의 해석이다.
관련
- Spring MVC Controller: HTTP request를 application 흐름으로 연결하는 서버 측 경계다.
- Layered Application Boundary: REST Controller가 도메인 규칙을 직접 처리하지 않도록 하는 내부 구조다.