로이 필딩이 처음 의도한 REST API

---

로이 필딩이 처음 의도한 REST API

로이 필딩(Roy Fielding)이 2000년 박사학위 논문 "Architectural Styles and the Design of Network-based Software Architectures"에서 처음 제안한 REST(Representational State Transfer)는 오늘날 흔히 사용되는 'REST API'와는 다소 차이가 있다. 필딩이 의도한 REST는 특정 기술이나 프로토콜이 아닌, 분산 하이퍼미디어 시스템(예: 월드 와이드 웹)을 위한 아키텍처 스타일(Architectural Style)이다. 이는 웹의 확장성, 일반성, 독립적인 진화를 지원하기 위한 설계 원칙들의 집합이다.

1. REST의 탄생 배경과 핵심 사상

필딩은 HTTP/1.0 및 1.1 표준 제정에 참여하면서 웹이 어떻게 성공적으로 확장될 수 있었는지에 대한 아키텍처 원칙들을 정리하고 체계화했다. REST는 바로 이 웹의 아키텍처를 개념적으로 설명하고, 더 나은 방향으로 발전시키기 위한 프레임워크였다.

핵심 사상은 '자원의 표현(Representation)에 의한 상태 전이'이다. 여기서 '자원(Resource)'은 웹상에 존재하는 모든 정보(문서, 이미지, 서비스 등)를 의미하며, '상태 전이(State Transfer)'는 클라이언트가 서버가 제공하는 자원의 '표현(Representation)'을 통해 애플리케이션의 상태를 변경하는 것을 말한다. 예를 들어, 사용자가 웹 페이지의 링크를 클릭함으로써 다른 페이지로 이동하는 행위 자체가 상태를 전이시키는 과정이다.

2. REST를 구성하는 6가지 아키텍처 제약 조건

필딩은 REST 아키텍처를 따르기 위해 반드시 지켜야 할 6가지 제약 조건을 정의했다. 이 조건들을 모두 충족해야만 진정한 'RESTful' 시스템이라고 할 수 있다.

1) 클라이언트-서버(Client-Server)

• 관심사의 분리(Separation of Concerns)가 핵심 원칙이다.
• 클라이언트는 사용자 인터페이스에 집중하고, 서버는 데이터 저장 및 처리에 집중한다.
• 이 분리를 통해 각 컴포넌트는 독립적으로 발전하고 확장될 수 있다. 클라이언트는 여러 플랫폼을 위해 개발될 수 있고, 서버는 복잡성을 단순화하여 확장성을 개선할 수 있다.

2) 무상태성(Stateless)

• 서버는 클라이언트의 세션 상태를 저장하지 않는다.
• 각 요청은 서버가 해당 요청을 이해하고 처리하는 데 필요한 모든 정보를 담고 있어야 한다.
• 이로 인해 서버는 각 요청을 독립적으로 처리할 수 있어 가시성, 신뢰성, 확장성이 향상된다.

3) 캐시 가능(Cacheable)

• 클라이언트는 서버의 응답을 캐시할 수 있어야 한다.
• 서버는 응답 데이터가 캐시 가능한지 아닌지를 명시해야 한다.
• 잘 관리되는 캐시는 네트워크 효율성을 높이고, 사용자 인지 성능을 개선하며, 서버의 부하를 줄여준다.

4) 계층화된 시스템(Layered System)

• 클라이언트는 최종 서버에 직접 연결되었는지, 중간 서버(프록시, 게이트웨이 등)를 통해 연결되었는지 알 수 없다.
• 중간 서버는 로드 밸런싱, 공유 캐시, 보안 정책 강화 등의 기능을 추가하여 시스템 전체의 확장성과 유연성을 향상시킨다.

5) 균일한 인터페이스(Uniform Interface)

REST 아키텍처에서 가장 핵심적이고 엄격하게 지켜져야 할 제약 조건이다. 이는 컴포넌트 간의 인터페이스를 일반화하여 전체 시스템 아키텍처를 단순화하고, 상호작용의 가시성을 높이며, 구현과 서비스가 독립적으로 진화할 수 있도록 한다. 균일한 인터페이스는 다음 네 가지 하위 제약 조건으로 구성된다.

1. 자원의 식별(Identification of resources)
   • 요청에 포함된 개별 자원은 URI(Uniform Resource Identifier)를 통해 고유하게 식별되어야 한다.
2. 표현을 통한 자원 조작(Manipulation of resources through representations)
   • 클라이언트는 자원의 표현과 그에 포함된 메타데이터를 통해 자원의 상태를 변경할 수 있어야 한다. GET, POST, PUT, DELETE와 같은 표준 HTTP 메서드를 사용하는 것이 이 원칙을 따르는 일반적인 방법이다.
3. 자기 서술적 메시지(Self-descriptive messages)
   • 각 메시지(요청과 응답)는 그 자체로 메시지를 어떻게 처리해야 하는지에 대한 충분한 정보를 포함해야 한다. 예를 들어, Content-Type 미디어 타입을 통해 표현의 형식을 명시하고, 메시지가 어떤 메서드를 지원하는지 등을 설명할 수 있어야 한다.
4. 하이퍼미디어로서의 애플리케이션 상태 엔진(Hypermedia As The Engine Of Application State, HATEOAS)
   • 필딩이 가장 강조했지만 오늘날 많은 'REST API'에서 간과되는 원칙이다.
   • 클라이언트는 초기 URI 외에 애플리케이션의 상태를 전이시키기 위한 어떤 사전 정보도 가지고 있어서는 안 된다.
   • 모든 애플리케이션 상태 전이는 서버가 응답으로 제공하는 하이퍼미디어 링크를 통해 동적으로 이루어져야 한다. 즉, 클라이언트는 서버가 제공하는 링크를 따라가기만 하면 되므로, 서버의 기능이나 URI 구조가 변경되어도 클라이언트는 영향을 받지 않는다.

6) 주문형 코드(Code-On-Demand) - 선택 사항

• 서버는 클라이언트에 실행 가능한 코드(예: JavaScript)를 전송하여 클라이언트의 기능을 일시적으로 확장하거나 맞춤화할 수 있다.
• 이 제약 조건은 선택 사항이며, 모든 REST 시스템이 이를 구현할 필요는 없다.

3. 오늘날의 'REST API'와의 차이점

오늘날 많은 개발자들이 'REST API'라고 부르는 것은 단순히 HTTP 프로토콜을 사용하여 JSON/XML 형식으로 데이터를 주고받는 API를 의미하는 경우가 많다. 이는 필딩이 정의한 REST의 일부 요소, 특히 균일한 인터페이스 제약 조건 중 HATEOAS 원칙을 완전히 충족하지 못하는 경우가 대부분이다.

• 오늘날의 일반적인 API: 클라이언트는 API 문서를 통해 특정 작업을 수행하기 위해 어떤 URI로 어떤 요청을 보내야 하는지 미리 알고 있어야 한다. URI 구조가 바뀌면 클라이언트 코드도 변경되어야 한다.
• 필딩이 의도한 REST: 클라이언트는 오직 최초 진입점 URI만 알면 된다. 이후의 모든 상호작용은 서버가 동적으로 제공하는 하이퍼미디어 링크를 통해 이루어진다. 이로 인해 서버와 클라이언트의 결합도(coupling)가 극적으로 낮아진다.

4. 결론

로이 필딩이 처음 의도한 REST는 단순히 HTTP 메서드와 URI 규칙의 집합이 아니다. 이는 웹의 근본적인 아키텍처 원칙에 기반한, 독립적이고 확장 가능하며 유연한 분산 시스템을 구축하기 위한 설계 철학이다. 특히 '균일한 인터페이스'와 그 핵심 요소인 HATEOAS는 서버와 클라이언트가 독립적으로 진화할 수 있도록 하는 가장 중요한 원칙이다. 비록 오늘날 대부분의 API가 이 원칙을 완전히 따르지는 않지만, REST의 기본 제약 조건들을 이해하고 적용하려는 노력은 더 나은 웹 서비스를 설계하는 데 중요한 지침이 된다.

---