이전 포스팅에서 배운 REST API는 REST 아키텍처를 따르는 시스템입니다.
그리고 아키텍처 스타일은 제약조건의 집합이며, 6가지 제약 조건들이 존재합니다.

REST API의 6가지 제약 조건들

• 만약 이들 중 하나라도 지켜지지 않는다면 이는 REST API라고 할 수 없다.

1. Client-Server

• client는 server의 리소스 URI만 알고 있으면 된다.
• client는 server에서 어떤 일을 수행하더라도 내부 작업을 알지 않아도 된다.
• 이는 플랫폼의 이식성을 향상시킨다.
• client와 server가 독립적이라 별도의 진화가 가능하다.

2. Stateless

• HTTP 프로토콜의 특징 중 하나는 Stateless 하다는 것이므로 REST 역시 무상태성을 갖는다.
• client에서 server로 각 요청에는 그 요청에 필요한 모든 정보가 포함되어야 한다.

3. Cache

• 요청에 대한 응답 내의 데이터에 해당 요청은 캐시가 가능한지 불가능한지 명시해야한다. ( cacheable )
  - 일반적으로 Caching이 안 되는 Architecture가 좋은 Architecture라고 할 수 있을까...?
• 보통 HTTP Header에 cache-control 헤더를 이용한다.

4. Uniform Interface

• 전체적인 시스템 아키텍처를 간단하고 잘 파악할 수 있도록 하기 위한 약속된 Interface
  - Uniform한 형태를 띄지 않는다면 당연히 API가 늘어나고 사용자가 늘어날 수록 사용하기 힘들 것
• JSON이 가장 유명한 방식
• 개발 REST는 규약으로 4가지를 제시

5. Layered System

• 계층화된 시스템 아키텍처를 사용하여, 각 구성들 간의 계층을 마음대로 상호작용 할 수 없도록 제한함으로써 Interface를 일원화할 수 있다.
  - 모듈화된 프로그램을 만들 듯이 각 계층을 분리시켜 오류를 찾기 쉽고 관리하기 쉽도록 하는 것 같다.

6. Code-On-Demand (optional)

• server에서 코드를 client로 보내서 실행할 수 있어야 한다. ( ex. HTML의 javascript )
• 보안상 추천하지 않는다.

참고 및 출처
REST API Tutorial
HATEOAS를 모르면 당신이 알고 있는 REST API는 REST API가 아니라고 장담할게요.