REST

클라이언트-서버 아키텍처는 REST의 첫 번째 제약 조건으로, 시스템을 명확히 분리된 두 부분으로 구성한다. 클라이언트는 사용자 인터페이스와 비즈니스 로직에 집중하고, 서버는 데이터 저장, 비즈니스 규칙 처리 등 리소스 관리에 집중한다. 이 분리는 각 구성 요소의 독립적인 진화를 가능하게 한다.

이 아키텍처의 핵심은 관심사의 분리이다. 서버는 클라이언트의 상태나 구현 세부 사항을 알 필요 없이, 표준화된 API를 통해 요청을 처리하고 응답을 제공한다. 반대로 클라이언트는 서버의 내부 데이터 구조나 비즈니스 로직 구현 방식에 구애받지 않고, 서버가 제공하는 인터페이스만 이해하면 된다. 이는 서버 측의 기술 스택 변경이 클라이언트에 영향을 미치지 않도록 보장한다.

이러한 분리는 다음과 같은 실질적인 이점을 가져온다.

• 유지보수성 향상: 서버와 클라이언트를 독립적으로 수정하고 배포할 수 있다.

• 확장성: 서버와 클라이언트가 각자의 필요에 맞게 확장될 수 있다.

• 플랫폼 독립성: 다양한 플랫폼(웹, 모바일, 데스크톱)의 클라이언트가 동일한 서버와 상호작용할 수 있다.

결과적으로, 클라이언트-서버 아키텍처는 REST 시스템이 복잡성을 관리하고, 다양한 클라이언트 환경을 지원하며, 장기적으로 진화할 수 있는 기반을 제공한다.

무상태성은 REST 아키텍처의 핵심 제약 조건 중 하나이다. 이는 각 클라이언트 요청이 서버에 필요한 모든 정보를 포함해야 하며, 서버가 이전 요청의 컨텍스트를 저장하지 않아도 요청을 이해하고 처리할 수 있어야 함을 의미한다.

이 원칙에 따르면, 서버는 클라이언트의 세션 상태를 저장하지 않는다. 대신, 클라이언트는 요청마다 인증 토큰이나 세션 ID와 같은 상태 정보를 요청 헤더나 URI에 포함시켜 전송한다. 이는 서버의 확장성을 크게 향상시킨다. 서버가 상태를 유지할 필요가 없으므로, 요청은 시스템 내의 어떤 서버 인스턴스로도 라우팅될 수 있다. 이는 장애 복구와 부하 분산을 간단하게 만든다.

무상태성은 단순성과 신뢰성을 제공하지만, 모든 요청에 반복적으로 상태 정보를 포함시켜야 하므로 네트워크 오버헤드를 증가시킬 수 있다. 또한, 서버 측에서 관리되는 세션이 필요한 일부 애플리케이션(예: 실시간 협업 도구)에는 적합하지 않을 수 있다. 이러한 트레이드오프에도 불구하고, 대부분의 공개 API와 웹 서비스는 확장성과 단순성을 위해 무상태성을 채택한다.

캐시 가능성은 네트워크 성능을 최적화하기 위한 핵심 제약 조건이다. 서버의 응답은 명시적으로 캐시 가능 또는 불가능으로 표시되어야 하며, 클라이언트는 이후의 동일한 요청에 대해 캐시된 데이터를 재사용할 수 있다. 이는 불필요한 서버 호출을 줄여 응답 시간을 단축하고 서버 부하를 경감시킨다.

캐시 가능성을 구현하는 주요 메커니즘은 HTTP 헤더를 활용하는 것이다. 서버는 Cache-Control, Expires, ETag 등의 헤더를 통해 응답 데이터의 신선도를 제어한다. 예를 들어, Cache-Control: max-age=3600은 응답이 1시간 동안 캐시되어 유효함을 나타낸다. 클라이언트는 If-None-Match 헤더에 캐시된 리소스의 ETag 값을 담아 서버에 보내고, 리소스가 변경되지 않았다면 서버는 304 Not Modified 상태 코드로 응답하여 대역폭을 절약한다.

적절한 캐시 전략은 애플리케이션의 특성에 따라 달라진다. 자주 변경되지 않는 정적 리소스는 긴 캐시 수명을, 실시간 데이터는 캐시를 비활성화하거나 매우 짧은 수명을 설정한다. 잘 설계된 캐시 정책은 RESTful API의 확장성과 사용자 경험을 크게 향상시킨다.

계층화 시스템은 REST 아키텍처의 핵심 제약 조건 중 하나로, 시스템을 여러 계층으로 구성하여 각 계층이 하위 계층의 기능만을 사용하고, 그 상세 구현을 알지 못하도록 하는 원칙이다. 이는 시스템의 복잡성을 관리하고, 구성 요소 간의 결합도를 낮추며, 확장성을 높이는 데 기여한다.

일반적인 웹 애플리케이션에서는 클라이언트, 프록시 서버, 애플리케이션 서버, 데이터베이스 서버 등이 각각 별도의 계층으로 구성된다. 예를 들어, 클라이언트는 자신이 직접 애플리케이션 서버에 연결되었다고 생각하지만, 실제로는 중간에 로드 밸런서나 보안 게이트웨이를 거칠 수 있다. 이러한 중간 계층은 성능 향상을 위한 캐싱, 보안 강화, 요청 분산 등의 기능을 투명하게 제공한다.

이 제약 조건의 주요 이점은 다음과 같다.

따라서 계층화 시스템은 RESTful API가 복잡한 네트워크 환경에서도 견고하고 확장 가능하게 동작할 수 있는 기반을 제공한다. 클라이언트는 최종 서버와의 통신 경로에 여러 중간 요소가 존재함을 인지하지 못한 채, 균일한 인터페이스를 통해 상호작용한다.

코드 온 디맨드는 REST 아키텍처 스타일을 구성하는 여섯 가지 제약 조건 중 하나이다. 이 원칙은 서버가 클라이언트의 기능을 확장하기 위해 실행 가능한 코드를 전송할 수 있도록 허용한다. 예를 들어, 서버는 자바스크립트나 플래시 애플릿과 같은 스크립트를 클라이언트에 보내, 클라이언트 측에서 추가적인 로직을 실행하게 할 수 있다.

이 제약 조건은 다른 원칙들에 비해 선택적이며, 실제 RESTful API 설계에서 필수적으로 적용되지는 않는다. 많은 REST 서비스는 클라이언트에 코드를 전송하지 않고, 데이터 표현만을 교환하는 방식을 채택한다. 코드 온 디맨드의 적용 여부는 클라이언트의 능력과 보안 정책에 크게 의존한다.

이 원칙의 주요 이점은 클라이언트의 기능을 사전에 모두 정의할 필요 없이, 필요에 따라 서버가 클라이언트의 동작을 확장하거나 수정할 수 있다는 점이다. 이를 통해 클라이언트의 유연성을 높이고, 배포 후에도 새로운 기능을 추가할 수 있다. 그러나 보안상의 위험[1]과 클라이언트 측 실행 환경에 대한 의존성으로 인해, 현대 웹 애플리케이션에서는 제한적으로 사용되는 편이다.

균일한 인터페이스는 REST 아키텍처 스타일의 핵심 제약 조건이다. 이는 클라이언트와 서버 간의 인터페이스를 단순하고 표준화된 방식으로 정의하여, 시스템 전체의 아키텍처를 단순화하고 상호 운용성을 높이는 원칙이다. 이 제약 조건은 네 가지 구체적인 하위 원칙으로 구성된다.

첫째, 리소스 식별이다. 모든 정보는 고유한 식별자, 일반적으로 URI를 통해 리소스로 식별되어야 한다. 예를 들어, /books/123은 ID가 123인 특정 책 리소스를 가리킨다. 둘째, 표현을 통한 리소스 조작이다. 클라이언트는 리소스 자체를 직접 조작하는 대신, 그 리소스의 표현(예: JSON 또는 XML 형식의 데이터)을 주고받음으로써 리소스를 조작한다. 서버는 요청된 리소스의 완전한 표현을 전송하여 클라이언트가 이를 수정할 수 있게 한다. 셋째, 자기 서술적 메시지이다. 각 메시지에는 메시지를 어떻게 처리해야 하는지에 대한 충분한 정보가 포함되어야 한다. 이는 주로 HTTP 메서드(GET, POST, PUT, DELETE 등)와 미디어 타입(Content-Type)을 통해 이루어진다. 넷째, 애플리케이션 상태의 엔진으로서의 하이퍼미디어이다. 이는 HATEOAS로 알려진 개념으로, 클라이언트가 서버로부터 초기 URI만으로 접근한 후, 서버가 동적으로 제공하는 하이퍼링크를 통해 애플리케이션의 상태를 전이할 수 있어야 함을 의미한다.

균일한 인터페이스의 채택은 시스템에 명확한 장단점을 가져온다. 장점으로는 인터페이스가 표준화되고 단순해져 독립적인 진화가 쉬워지고, 캐싱 효율성이 향상되며, 시스템 가시성이 개선된다. 반면, 모든 상호작용이 고정된 인터페이스에 맞춰져야 하므로 특정 작업에 최적화된 형태보다는 일반화된 형태로 데이터를 전송하게 되어, 경우에 따라 효율성이 떨어질 수 있다는 단점도 존재한다[2].

URI는 RESTful API에서 정보의 대상인 리소스를 고유하게 식별하는 주소 역할을 한다. 모든 리소스는 하나의 논리적 URI를 가져야 하며, 이 URI를 통해 클라이언트는 해당 리소스에 접근하고 조작한다. URI 설계의 핵심은 리소스의 구조를 직관적이고 예측 가능하게 반영하는 것이다.

리소스는 일반적으로 명사로 표현되며, URI 경로는 계층 관계를 나타내기 위해 사용된다. 예를 들어, 사용자 리소스와 그 사용자가 작성한 게시글 리소스는 /users/{user-id}/posts와 같은 계층적 구조로 설계할 수 있다. 이때 URI는 리소스 자체를 식별하는 데 집중해야 하며, 리소스에 대한 연산이나 액션은 URI에 포함시키지 않는 것이 원칙이다. 즉, /users/123/activate보다는 사용자 리소스의 상태를 표현(Representation)에 포함시키고, PUT 또는 PATCH 메서드로 상태를 변경하는 방식이 선호된다.

URI 설계 시 일반적으로 다음의 규칙과 모범 사례를 따른다.

마지막으로, URI는 변경되지 않고 안정적으로 유지되어야 한다. 한 번 공개된 URI는 클라이언트가 의존하게 되므로, 하위 호환성을 깨는 변경을 최소화해야 한다. 버전 관리가 필요할 경우 URI 경로(/api/v1/users)나 HTTP 헤더에 버전 정보를 명시하는 방법을 사용한다.

HTTP 메서드는 RESTful API에서 리소스에 대한 조작을 정의하는 동사를 나타낸다. 각 메서드는 특정한 의미와 부작용을 가지며, 이를 올바르게 활용하는 것이 REST의 원칙을 따르는 설계의 핵심이다.

주로 사용되는 메서드와 그 역할은 다음과 같다.

GET과 HEAD 메서드는 안전한 메서드로 간주되며, 서버의 상태를 변경하지 않고 정보를 가져오는 데만 사용해야 한다. PUT과 DELETE 메서드는 멱등성을 가진다. 즉, 동일한 요청을 여러 번 보내도 한 번 보낸 것과 같은 효과를 낸다. 반면 POST는 멱등성이 보장되지 않으며, 동일한 요청을 반복하면 새로운 리소스가 계속 생성될 수 있다.

메서드를 올바르게 선택하는 것은 API의 직관성과 신뢰성을 높인다. 예를 들어, 리소스 조회에는 GET을, 생성에는 POST를, 전체 수정에는 PUT을, 삭제에는 DELETE을 사용한다. 이러한 일관된 사용은 클라이언트 개발자가 API의 동작을 쉽게 예측할 수 있게 한다.

RESTful API에서 클라이언트와 서버는 리소스에 대한 정보를 주고받을 때, 리소스 자체가 아닌 그 리소스의 '표현(Representation)'을 교환합니다. 표현은 리소스의 특정 시점의 상태를 담고 있는 데이터 형식으로, 주로 JSON이나 XML이 널리 사용됩니다. 서버는 클라이언트의 요청에 따라 적절한 표현 형식으로 리소스 상태를 반환하고, 클라이언트는 받은 표현을 해석하여 정보를 얻거나 상태를 변경하기 위한 새로운 표현을 서버에 전송합니다.

표현 형식의 선택은 API의 호환성과 사용성에 직접적인 영향을 미칩니다. JSON은 경량의 데이터 교환 형식으로, 가독성이 좋고 대부분의 프로그래밍 언어에서 쉽게 파싱 및 생성할 수 있어 현대 웹 API의 사실상 표준으로 자리 잡았습니다. 반면 XML은 문서 구조의 유효성을 엄격하게 검증할 수 있는 스키마를 지원하고 네임스페이스 등 복잡한 구조를 표현하는 데 강점이 있지만, 상대적으로 장황하고 처리 비용이 높은 편입니다.

클라이언트가 원하는 표현 형식을 지정하는 방법은 주로 HTTP 헤더를 통해 이루어집니다. Accept 헤더를 사용하여 요청 시 선호하는 미디어 타입(예: application/json, application/xml)을 서버에 알릴 수 있습니다. 이에 따라 서버는 콘텐츠 협상을 수행하여 적절한 표현을 반환합니다. 또한 서버는 응답에 Content-Type 헤더를 포함하여 실제로 반환된 표현의 형식을 명시합니다.

일부 API는 리소스의 다른 표현을 제공하기 위해 URI 확장자(예: /users/1.json, /users/1.xml)를 사용하기도 하지만, HTTP 헤더를 통한 협상을 선호하는 것이 REST 원칙에 더 부합하는 일반적인 관행입니다.

REST는 HTTP와 같은 기존의 웹 표준을 활용하여 구현의 단순성과 광범위한 호환성을 제공한다. 이는 학습 곡선이 비교적 완만하고, 개발 도구 및 인프라 지원이 풍부하다는 장점으로 이어진다. 또한 무상태성 원칙 덕분에 서버의 확장성이 뛰어나며, 캐시 가능성은 네트워크 효율과 응답 성능을 크게 향상시킨다.

RESTful API는 리소스 중심의 직관적인 설계를 지향한다. URI를 통해 리소스를 명시적으로 식별하고, 표준화된 HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용하여 조작한다. 이는 API의 구조와 의도를 이해하기 쉽게 만들어 개발자 간의 협업과 유지보수를 용이하게 한다.

다음은 REST의 주요 장점을 요약한 표이다.

마지막으로, 계층화 시스템 원칙은 보안, 로드 밸런싱, 암호화와 같은 기능을 중간 계층에 투명하게 추가할 수 있게 한다. 이는 시스템 전체의 복잡성을 관리하고 유연한 아키텍처 구성을 가능하게 한다.

REST는 단순성과 확장성으로 널리 채택되었지만, 특정 상황에서는 한계점을 보인다.

가장 큰 단점은 오버페칭과 언더페칭 문제이다. 클라이언트가 필요한 데이터만 정확히 요청하기 어려워, 필요 이상의 데이터를 받거나([4]) 반대로 필요한 데이터를 얻기 위해 여러 번의 요청을 보내야 하는 경우가 발생한다. 이는 네트워크 효율성을 저하시키고, 특히 모바일 환경에서 성능 문제를 일으킬 수 있다. 또한, 고정된 엔드포인트 구조는 클라이언트 요구사항이 빠르게 변화할 때 유연하게 대응하기 어렵게 만든다. 새로운 데이터 조합이 필요할 때마다 서버 측에 새 API를 설계해야 할 수 있다.

표준화된 HTTP 메서드와 상태 코드만을 사용한다는 원칙은 명확성을 주지만, 복잡한 비즈니스 로직을 표현하는 데는 제한적일 수 있다. 예를 들어, "주문 취소"나 "결제 승인" 같은 구체적인 액션은 POST 메서드 하나에 의존하게 되어, URI 설계가 동사 중심으로 흐르거나(/cancelOrder) 요청 본문에 액션 정보를 담는 등 일관성을 해치기 쉽다. 마지막으로, RESTful API는 일반적으로 요청-응답 모델에 기반하므로, 서버에서 클라이언트로의 실시간 데이터 푸시가 필요한 경우 웹소켓이나 Server-Sent Events 같은 별도의 프로토콜을 도입해야 한다는 부담이 있다.

SOAP는 XML 기반의 프로토콜로, 주로 웹 서비스 간의 구조화된 정보 교환을 위해 설계되었다. SOAP는 HTTP, SMTP, TCP 등 다양한 전송 프로토콜 위에서 동작할 수 있지만, 주로 HTTP와 결합하여 사용된다. SOAP 메시지는 XML로 정의된 엄격한 Envelope, Header, Body 구조를 가지며, WSDL이라는 별도의 XML 문서를 통해 서비스의 인터페이스를 명세한다.

SOAP는 REST와 비교했을 때 몇 가지 뚜렷한 차이점을 보인다. SOAP는 프로토콜 자체에 보안, 트랜잭션, 신뢰성 메시징 등 다양한 표준과 확장(WS-* 표준)을 내장하고 있어, 엔터프라이즈 환경에서 요구되는 복잡한 비즈니스 로직과 높은 보안 수준을 지원하는 데 유리하다. 반면, 이러한 엄격함과 복잡성은 메시지 크기를 크게 만들고, 학습 곡선을 높이며, 캐싱이 어렵게 만드는 단점으로 작용한다.

다음 표는 REST와 SOAP의 주요 특징을 비교한 것이다.

요약하면, SOAP는 공식적인 계약(WSDL)과 강력한 내장 기능을 통해 엔터프라이즈 수준의 통합에 적합한 반면, REST는 웹의 기본 원리를 활용하여 더 간단하고 유연하며 확장 가능한 API를 구축하는 데 초점을 맞춘다.

GraphQL은 페이스북(현 메타)이 2012년 내부적으로 개발하고 2015년 공개한 API 쿼리 언어이자 런타임이다. REST가 고정된 엔드포인트에서 데이터를 반환하는 방식이라면, GraphQL은 클라이언트가 서버에 필요한 데이터의 구조와 필드를 정확히 지정하는 단일 엔드포인트를 사용한다. 이는 클라이언트가 한 번의 요청으로 여러 리소스의 데이터를 조합하여 가져오거나, 필요한 필드만 선택적으로 요청할 수 있게 한다.

GraphQL의 주요 특징은 다음과 같다.

GraphQL은 복잡한 관계를 가진 데이터를 효율적으로 가져오거나, 모바일 애플리케이션처럼 대역폭이 제한된 환경에서 과도한 데이터 전송을 줄이는 데 유리하다. 또한, API 버전 관리 없이도 타입 시스템에 필드를 추가하는 방식으로 진화가 가능하다는 장점이 있다. 그러나 단일 요청이 복잡한 데이터를 가져오는 과정에서 서버 측에 부하를 줄 수 있으며, HTTP 캐싱이 복잡해지는 단점도 있다.