SOAP API와 REST API

API(응용 프로그램 인터페이스)의 구조를 이야기할 때, 가장 대표적인 두 가지 방식으로 SOAP API와 REST API를 흔히 말한다. 두 가지 방식은 비슷하기는 하지만 본질적으로는 서로 다른 기술이다. SOAP는 프로토콜이고, REST는 아키텍처 스타일이다. 이 두 방식은 서로 다르게 구성되고, 서로 다르게 기능하며, 서로 다른 상황에서 사용된다. 

 

REST API란?

REST(Representational State Transfer)는 네트워크를 통해서 컴퓨터들끼리 통신할 수 있게 해주는 아키텍처 스타일이다. REST API는 인터넷 식별자(URI)와 HTTP 프로토콜을 기반으로 한다. 데이터 포맷으로는 브라우저 간 호환성이 좋은 제이슨(JSON)을 사용한다. 

REST API는 구축과 확장이 간단하지만, 크고 복잡하게 만들 수도 있다. 이는 API를 어떻게 만들고, 무엇을 추가하고, 어떤 목적으로 설계되었는지에 따라 달려있다. REST API는 클라이언트와 서버 사이에서 통신할 수 있게 하고, 아키텍처를 만들 수 있게 해준다. REST 방식의 API라면, 클라이언트-서버 모델로 구축되었다는 것을 의미하며, 정보의 페이로드(실제 전달하려는 내용)가 두 지점 사이를 왕복하게 된다.

REST API는 단일한 인터페이스를 사용한다. 이러한 점 때문에 해당 API를 사용하는 애플리케이션들이 동일한 경로를 통해서 접속해야 하고, 그 방식이 단순하다. 여기에는 장점도 있고, 단점도 있기 때문에 향후 개발 과정에서 어떤 영향이 있는지에 대해서 알고 싶다면 전문가와 상의해보는 것이 좋다.

REST는 웹에 최적화되어 있고, 데이터 포맷이 JSON이기 때문에 브라우저들 간에 호환성이 좋다. 또한, 그 성능과 확장성이 뛰어나다. 하지만 다른 기술들과 마찬가지로 그 자체의 기능이 정지되거나 앱을 먹통으로 만들 수도 있다. 그래서 REST로는 풀지 못하는 문제들을 해결하기 위해서 그래프 QL과 같은 언어가 생겨난 것이다.

 

REST API의 장점을 정리해보자면 다음과 같다. 

1. 통합 

API는 새로운 애플리케이션을 기존 소프트웨어 시스템과 통합하는 데 사용된다. 그러면 각 기능을 처음부터 작성할 필요가 없기 때문에 개발 속도가 빨라진다. API를 사용하여 기존 코드를 활용할 수 있다.

2. 혁신 

새로운 앱의 등장으로 전체 산업이 바뀔 수 있다. 기업은 신속하게 대응하고 혁신적인 서비스의 신속한 배포를 지원해야 한다. 전체 코드를 다시 작성할 필요 없이 API 수준에서 변경하여 이를 수행할 수 있다.

3. 확장

API는 기업이 다양한 플랫폼에서 고객의 요구 사항을 충족할 수 있는 고유한 기회를 제공한다. 예를 들어 지도 API를 사용하면 웹 사이트, Android, iOS 등을 통해 지도 정보를 통합할 수 있다. 어느 기업이나 무료 또는 유료 API를 사용하여 내부 데이터베이스에 유사한 액세스 권한을 부여할 수 있다.

4. 유지 관리의 용이성

API는 두 시스템 간의 게이트웨이 역할을 한다. API가 영향을 받지 않도록 각 시스템은 내부적으로 변경해야 한다. 이렇게 하면 한 시스템의 향후 코드 변경이 다른 시스템에 영향을 미치지 않는다.

SOAP API란?

SOAP(Simple Object Access Protocol)는 그 자체로 프로토콜이며, 보안이나 메시지 전송 등에 있어서 REST보다 더 많은 표준들이 정해져있기 때문에 조금 더 복잡하다. 이러한 표준들로 인해서 오버헤드가 많기는 하지만, 보안, 트랜잭션, ACID(원자성, 일관성, 고립성, 지속성)을 준수해야 하는 보다 종합적인 기능이 필요한 조직에게는 적합한 방식이 될 수 있다. 굳이 비교를 하자면, SOAP는 웹 서비스 시나리오에 적용하기에는 그다지 좋지 않기 때문에, 기업용 애플리케이션 등을 작업하는데 더 이상적이라고 말할 수 있다.

SOAP에서는 SSL도 지원하고 WS-Security라는 자체 표준의 보안 기능도 가지고 있기에 보안 수준이 엄격하다. 따라서 은행용 모바일 앱처럼 보안 수준이 높아야 하거나, 신뢰할 수 있는 메시징 앱, 또는 ACID를 준수해야 하는 경우라면 SOAP 방식이 선호된다.

REST에서는 표준화된 메시징 시스템이 갖춰져 있지 않으며, 통신 장애가 있을 경우 재시도를 통해서만 조치할 수 있다. 반면 SOAP 표준에는 성공/반복 실행 로직이 규정되어 있기 때문에, SOAP API를 통해서 통신을 할 때 처음부터 끝까지 신뢰성을 제공한다.

또한 ACID를 준수하기 때문에 데이터의 변형을 줄여주고, 데이터베이스와의 상호작용에 대해서 사전에 정확하게 정하기 때문에 데이터의 무결성을 지켜준다. ACID는 데이터 일관성을 위한 다른 방식들보다도 더 보수적이기 때문에, 금융 정보 등의 민감한 데이터를 주고받을 때 일반적으로 많이 사용된다.

 

정리 

위에서도 언급했듯이,SOAP는 프로토콜이고, REST는 아키텍처 스타일이다. API는 애플리케이션이 서버에 접속할 수 있도록 설계된 일종의 도구이다. SOAP는 서비스 인터페이스를 이용해서 서버에 접근하고, REST는 URI를 이용해서 접근한다. 

API라는 것은 결국은 앱의 페이로드를 처리하기 위해서 만들어진 것인데, ‘SOAP과 REST의 차이’는 페이로드를 처리하는 방식에 있다. 페이로드는 인터넷을 통해서 전송되는 데이터이다. 그렇기 때문에 페이로드가 ‘무거운’경우에는 더 많은 리소스가 필요하다. REST는 HTTP와 JSON을 사용하기 때문에 페이로드의 무게를 가볍게 할 수 있다다. 하지만 SOAP에서는 XML에만 의존한다.

‘SOAP과 REST의 차이’는 보안을 다루는 방식에서도 볼 수 있다. SOAP는 WS-Security를 지원하는데, WS-Security는 전송 레벨에서 아주 뛰어나며 SSL보다도 조금 더 복잡하기 때문에 기업용 보안 도구에 통합하는데 보다 이상적이다. REST에서는 HTTP의 보안 버전인 HTTPS 프로토콜을 이용할 수 있다. 둘의 공통점은 둘 다 양단간(end-to-end) 보안성을 위해서 SSL을 지원한다는 점이다.

SOAP는 서버와 긴밀하게 연결하며, REST는 보다 느슨한 형태로 연결된다. 프로그래밍을 할 때는 일반적으로 추상화 계층이 더 많을수록 양쪽의 상호작용에서 통제할 수 있는 부분이 줄어들기는 하지만 오히려 구현하기는 쉬우며, 나중에 그 방식을 전부 고치지 않고도 업데이트를 쉽게 할 수 있는 편이다. API를 이용해서 서버와 상호작용할 때에도 마찬가지다. 그리고 바로 이 부분에서 ‘SOAP과 REST의 차이’를 볼 수 있다. SOAP는 서버와 매우 긴밀하게 연결되기 때문에 그 통신 방식이 매우 엄격하며, 그래서 수정이나 업데이트를 하는 것이 보다 더 어렵다. REST 방식의 API에서는 클라이언트에서 해당 API가 필요하지 않지만, SOAP 방식의 API에서는 상호작용을 시작할 때조차도 클라이언트에서 API에 관한 모든 정보들을 필요로 한다.