API 아키텍처s (feat. WSDL 연동하기...)

백앤드 개발을 하면서 RESTful한 API은 자주 사용하였지만, 다른 API 아키텍처를 반영하는 경우는 거의 없었다. 특히 SOAP과 같은 조금은 오래된 기술들은 개념적으로 잠깐 찾아본적은 있어도 동작 방식이나 사용방법은 전혀 알지 못했다. 최근에 진행한 프로젝트에서 타사 프로그램을 연동하는 과정에서 WSDL를 통해 연동을 진행했는데 이때 배운 내용을 기록하고자 블로그를 작성한다.

다양한 아키텍처

둘 이상의 개별 애플리케이션이 통신하기 위해 개발자는 한시스템에서 다른 시스템의 정보나 기능에 접근할수있도록 API (Application Programming Interface) 라는 브릿지를 구축한다. 다양한 애플리케이션을 빠르고 대규모로 통합하기 위해서는 프로토콜 or Spec에 맞게 네트워크를 통해 전달되는 메세지의 의미, 구문을 정의한다. 이러한 사양이 바로 API 아키텍처이다.

시간이 지나가며 API 아키텍처도 다양한 방식으로 고도화되고 있다. 아래의 그림은 API 아키텍처의 발전과정을 볼수있는 타임라인이다.

출처 : Rob Crowley

각 아키텍처마다 데이터 교환에 대한 고유한 표준화 패턴을 가지고 있으며, 선택의 폭이 넓어짐에 따라 어떤 아키텍처가 적합한지에 대해서는 다양한 의견이 있고 현대의 API는 대부분 REST를 가리킨다. 하지만 기술의 실제 속성과 특성을 고려하지 않은채 기술 자체를 인기에 따라 편향적으로 선택하는 것은 지양해야한다. 자 그럼 본론에 들어가기 전에 간단하게 아래 그림을 확인해보자.

architecture

REST

REST는 Representational State Transfer의 약자로, 2000년도에 로이필딩 박사를 통해 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST가 발표되었다. 이러한 REST는 아래 3가지로 구성된다.

• 자원(Resource) - URI
• 행위(Verb) - HTTP Method
• 표현(Representations)

REST 아키텍처는 제한 조건을 준수하며 각 개별 컴포넌트는 제한조건안에서 자유롭게 구현이 가능하다. 아래의 6가지 제한조건을 확인해보자.

1. 인터페이스 일관성
   • URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행하는 아키텍처 스타일
2. 무상태(stateless)
   • 작업을 위한 상태정보를 따로 저장하고 관리하지 않는다.
   • 세션정보, 쿠키 정보를 별도로 저장 관리 하지않아 API 서버는 들어오는 요청만을 단순히 처리한다.
   • 서비스 자유도 상승, 서버에서 불필요한 정보 관리 X
3. 캐시 처리 가능(cacheable)
   •  HTTP라는 기존 웹표준을 그대로 사용하여 HTTP의 캐싱기능 사용이 가능
   • HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능
4. 계층화(layer system)
   • REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간매체를 사용할 수 있게 한다.
5. 클라이언트/서버 구조
   • REST 서버는 API 제공, 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조
   • 각각의 역할이 확실히 구분되기 때문에 클라이언트와 서버에서 개발해야 할 내용이 명확해지고 서로간 의존성이 줄어든다.
6. Code on demand (optional)
   • 자바 애플릿이나 자바스크립트의 제공을 통해 서버가 클라이언트가 실행시킬 수 있는 로직을 전송하여 기능을 확장시킬 수 있다.

이러한 내용을 바탕으로 REST API를 디자인 할때 URI는 정보의 자원을 표현해야하며, 자원에 대한 행위는 HTTP Method로 표현하는 2가지의 내용을 꼭 기억자.

SOAP

SOAP(Simple Object Access Protocol)은 네트워크를 통해 구조화된 정보를 교환하기 위한 XML 기반의 프로토콜이다. SOAP API는 일반적으로 HTTP 프로토콜을 사용하지만 SMTP, TCP와 같은 프로토콜 사용도 가능하다. SOAP API는 높은 수준의 프로토콜 추상화를 제공하고 암호화 / 트랜잭션 관리와 같은 고급 기능을 지원한다. 은행 및 금융 도메인 등에서 보안을 이유로 SOAP을 사용한다.

SOAP API의 로직은 웹서비스 기술언어인 WSDL로 작성된다. WSDL은 엔드포인트를 정의하고 수행가능한 모든 프로세스를 설명한다. XML 데이터 형식은 많은 제약을 요구하는데 아래 이미지를 참고해보자.

SOAP 예시

• 모든 메세지를 시작하고 끝내는 envelope 태그
• 요청과 응답을 포함하는 본문
• 메세지에 특정 사항이나 추가 요구하사항을 결정하는 헤더
• 요청 처리과정 전반에 걸쳐 발생할수있는 오류

이러한 SOAP은 언어와 플랫폼에 구애받지 않고 다양한 전송 프로토콜에 바인딩이 가능하다. 또한 오류 처리 기능이 내장되어 Retry XML 로 메세지 반환이 가능하며 다양한 보안 확장 기능을 제공한다. 하지만 XML 구조만 지원하며 XML파일 기반의 단점인 파일 크기가 커서 비용이 증가한다. 또한 생태계가 작아 레퍼런스를 찾기가 어렵다. 이러한 이유로 SOAP 아키텍처는 기업 내부에서 통합을 진행하거나, 신뢰성 있는 파트너와의 연동에서 사용된다.

WSDL에 대해 좀더 자세히 알아보고 싶다면 링크를 참고하자. 이번 연동 과정에서 도움을 받았던 내용이다.