REST 제약조건

로이 필딩은 논문에서 REST의 제약 조건으로 다음과 같이 6가지를 제안하였습니다. 각각의 의미를 간단하게 살펴보도록 할게요.

첫 번째 제약 조건: Client-Server(클라이언트-서버)

• API를 통해 정보를 교환하는 주체는 클라이언트와 서버 구조를 가져야 한다.
• 클라이언트와 서버의 분리를 통해 서로 의존하지 않는 구조를 가져야 한다. (관심사의 분리)

두 번째 제약 조건: Stateless(무상태성)

• 클라이언트는 상태를 저장하지 않는다.
• 클라이언트의 각 리퀘스트는 서버가 리퀘스트를 이해하는 데에 필요한 모든 정보를 포함해야 한다.

세 번째 제약 조건: Cache(캐시)

• 데이터 복사본을 임시 저장 위치에 저장하여 보다 빠르게 액세스할 수 있도록 하는 프로세스인 캐싱을 통해 네트워크 효율성을 높인다.
• 리퀘스트에 대한 리스폰스에 캐시 가능 및 불가능 여부가 들어 있어야 한다.

네 번째 제약 조건: Uniform Interface(일관된 인터페이스)

• 전체 시스템을 잘 파악할 수 있도록 일관된 인터페이스를 제공해야 한다.
• 이를 통해 구현체가 서비스와 별도로 독립적으로 진화할 가능성을 얻게 된다. (낮은 결합도)
  • 예를 들어 클라이언트가 업데이트되어도 서버를 함께 업데이트할 필요가 없어진다. (반대의 경우에도 해당)

다섯 번째 제약 조건: Layered System(계층화된 시스템)

• 클라이언트는 서버에 직접 연결되었는지, 중간 서버를 통해 연결되었는지 알 수 없어야 한다.

여섯 번째 제약 조건: Code on Demand(주문형 코드)

• 서버에서 보낸 코드를 클라이언트에서 실행할 수 있어야 한다. (e.g. JavaScript)
• 선택적 제약 조건이며 지키지 않아도 REST에는 문제가 없다.

내용도 많고 뭔가 복잡해 보여서 위와 같은 제약 조건들을 모두 지키며 API를 설계할 수 있을지 걱정되실 수도 있을 텐데요.

하지만 너무 걱정하실 필요는 없습니다. 서버-클라이언트 구조의 웹 서비스에서 HTTP 프로토콜을 사용하여 리퀘스트와 리스폰스를 주고받는다면 **네 번째 제약 조건: Uniform Interface(일관된 인터페이스)**을 제외한 5개 제약 조건의 대부분이 지켜지게 됩니다.

이는 HTTP 프로토콜의 특징 덕분인데요. HTTP의 해당 특징에는 어떤 것들이 있는지, 또 각 특징이 REST의 어떤 제약 조건을 만족시키는지 한번 확인해 보겠습니다.

HTTP의 특징이 만족시키는 REST의 제약 조건

• 리퀘스트(클라이언트)와 리스폰스(서버)의 구조 → 첫 번째 제약 조건: Client-Server(클라이언트-서버) 만족
• stateless(무상태성)과 connetionless(비연결성) → 두 번째 제약 조건: Stateless(무상태성) 만족
• 헤더의 Cache-Control를 통한 캐시 가능 여부 명시 → 세 번째 제약 조건: Cache(캐시) 만족
• 리퀘스트와 리스폰스를 보내는 주체는 중간 계층을 신경 쓰지 않아도 되는 구조 → 다섯 번째 제약 조건: Layered System(계층화된 시스템) 만족
• 서버의 코드를 담을 수 있는 Body → 여섯 번째 제약 조건: Code on Demand(주문형 코드) 만족

그렇다면 **네 번째 제약 조건: Uniform Interface(일관된 인터페이스)**은 어떻게 지킬 수 있을까요?

이 제약 조건은 개발자가 API를 만들 때 가장 영향을 많이 받는 제약 조건입니다.

흔히 "API를 만든다"라고 하면, '어디로 어떻게 무엇을 담아 요청을 보내야 하는지'를 정하게 되는데, 그것을 결정하는 제약 조건이, 네 번째 제약 조건인 Uniform Interface 제약 조건입니다.

Unifrom Interface 제약 조건에는 다음과 같은 4가지 하위 제약 조건이 있습니다.

• identification of resources (자원에 대한 식별)
• manipulation of resources through representations (표현을 통한 자원에 대한 조작)
• self-descriptive messages (자기 서술적 메시지)
• hypermedia as the engine of application state, HATEOAS (하이퍼미디어를 사용한 애플리케이션 상태 표현)