SOAP API 와 REST API 의 장단점 및 차이

🚩  먼저, API란?

  Application Programming Interfaced 의 약자로 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다. 인터페이스는 두 애플리케이션 간의 서비스 계약이라고 할 수 있는데, 이 계약은 요청과 응답을 사용하여 두 애플리케이션이 서로 통신하는 방법을 정의한다. API 문서에는 개발자가 이러한 요청과 응답을 구성하는 방법에 대한 정보가 들어 있다.

라고 AWS 공식 문서에 나와있다. 문장만 보면 이해하기 조금 어려울 수 있는데 쉽게 비유하면 서버와 클라이언트 간의, 혹은 서로 다른 컴퓨터(또는 기기 혹은 시스템 등) 간의 요청-응답 방식에 대한 소통 창구 또는 연결 다리 같은 존재라고 할 수 있겠다.

∙ 인터페이스(interface)
서로 다른 두 개의 시스템, 장치 사이에서 정보나 신호를 주고받는 경우의 접점이나 경계면이다. 즉, 사용자가 기기를 쉽게 동작시키는데 도움을 주는 시스템을 의미한다. 컴퓨팅에서 컴퓨터 시스템끼리 정보를 교환하는 공유 경계이다.

*출처 : 위키백과

 

 

  이 포스팅에서는 API 자체에 관한 자세한 설명은 생략한다. 관련 자료 중에 더 전문적인 내용도 많이 있기도 하고, 무엇보다 직접 프로그래밍 해보며 찾아보는 것을 추천한다. 오늘 다뤄볼 내용은 기초지식에 관한 도서와 관련된 온라인 강의를 듣다가 과거에 많이 사용되었던 방식과 오늘날의 방식을 좀 더 알아보기 위해 비교하는 포스팅이므로 참고바란다.

 

 

 

---

🆚  SOAP과 REST ?

출처 : https://www.appsierra.com/blog/difference-between-rest-and-soap-apis

 

사실 이 두 가지는 API방식들 중에 하나라고 해도 깊은 내용으로 비교하기는 어렵다. 근본이 다르다고나 할까? SOAP는 프로토콜이고, REST는 아키텍처 스타일이기 때문이다. 그래서 오늘은 각각의 설명과 함께 현재는 왜 REST 방식이 많이 쓰이는지까지 다뤄보기로 한다. 

 

 

 

 

---

💬  SOAP API 의 특징 (REST API가 유행하는 이유)

  Simple Object Access Protocol의 약자로, 단순 객체 접근 프로토콜 자체를 말한다. 클라이언트와 서버 간에 XML의 형식으로 정보를 교환한다. 과거에 많이 쓰였고, 데이터 형식으로도 그렇고 유연성이 떨어지고 REST에 비해 무겁고 속도 저하 등의 문제가 있다.

하지만, 오늘날에도 전혀 쓰이지 않는 것은 아니다. REST 방식이 유행하는데도 불구하고 SOAP 방식을 사용하는 데에는 어떤 이유일까?

 

우선 SOAP은 WS-Security를 지원하는데 이는 전송 레벨에서 아주 뛰어나며 SSL보다도 조금 더 복잡하기 때문에 기업용 보안 도구에 통합하는데 보다 이상적이다. 또한, 프록시나 방화벽에 구애받지 않고 플랫폼이나 프로그래밍 언어로부터 독립적인 특징이 있어 분산 환경에 적합하다. 무엇보다 웹 서비스를 제공하기 위한 표준(WSDL: 웹 서비스 기술 언어 , UDDI: 전역 비즈니스 레지스트리 등)이 잘 정립되어 있다.

* 웹 서비스 표준기술에 관해

 

그렇다면 앞서 말했듯이 이러한 특징에도 불구하고 오늘날엔 왜 REST 방식이 널리 사용되게 되었을까?

가장 큰? 결정적인? 이유라고 한다면, JSON으로 통신하는 REST와는 달리 SOAP에서는 XML로 통신하기에, 복잡한 구조를 가지고 있으며 이는 확장성을 저해한다. 또한 언급했듯 무겁고 속도가 느린 단점은 개발 서비스에 있어 치명적이며 개발 난이도가 높아 개발환경의 지원이 필요하다.

 

 

SOAP에 관하여는 여기까지 알아두기로 하고 다음으로 넘어가 REST에 대해 알아보자.

 

 

 

---

❓  REST API란? 

  Representational State Transfer의 약자, 오늘날 웹에서 볼 수 있는 가장 많이 사용되고 있고 유연한 API 방식이다. 클라이언트가 서버에 요청을 데이터로 전송하면 서버가 이 클라이언트로부터 입력된 요청을 통해 서버 내부의 함수를 실행하고 이에 따른 응답 데이터를 클라이언트에 반환한다. 

 

* 탄생 일화

로이 필딩(Roy Fielding)의 박사학위 논문에서 최초로 소개되었으며, 그는 HTTP의 주요 저자 중 한 사람으로 그 당시 웹(HTTP) 설계의 우수성에 비해 제대로 사용되지 못하는 것에 안타까워하며 웹의 장점을 최대한 활용할 수 있는 아키텍처로써 REST를 발표했다고 한다.

 

REST API를 설계할 때, 이 특징을 따라 디자인(설계)한 API를 RESTful한 API라고 하는데 이 특징은 바로 다음과 같다.

• URI는 정보의 자원을 표현해야 한다.
• 자원에 대한 행위는 HTTP Method로 표현해야 한다.

 

따라서, REST 구성의 키워드는 이렇다 할 수 있다.

• 자원(RESOURCE) : URI
• 행위(Verb) : HTTP Method
• 표현(Representations)

위의 원칙과 구성을 한 문장으로 말하자면 "REST API는 URI를 통해서 자원을 나타내고, 해당 자원의 행위를 HTTP Method를 통해 규정하여 그 결과를 나타내는 것을 의미한다.

 

 

 

---

🪄 REST의 특징은? 왜 사용할까?

REST의 특징은 총 6가지가 있다.

• Uniform (유니폼 인터페이스) 
• Stateless (무상태성)
• Cacheable (캐시 가능)
• Self-descriptiveness (자체 표현 구조)
• Client - Server 구조
• Hierarchical system (계층형 구조)

1. Uniform Interface : URI로 지정한 리소스에 대한 조작을 통일되게 하는 인터페이스 스타일로, 정의된 인터페이스로서 구현한다면 특정 언어나 기술의 종속받지 않고 사용이 가능한 구조이다.
2. Stateless : REST는 작업을 위한 상태 정보를 따로 저장 및 관리하지 않는다. 세션 정보나 쿠키 정보를 별도로 저장하고 관리하지 않기 때문에 API 서버는 들어오는 요청만을 단순히 처리하면 된다. 따라서 서비스의 자유도가 높아지고 서버에서 불필요한 정보를 관리하지 않아도 된다.
3. Cacheable : REST는 HTTP라는 기존 웹 표준을 그대로 사용한다. 따라서 웹에서 사용하는 기존 인프라를 활용할 수 있기 때문에 HTTP가 가진 캐싱 기능을 사용할 수 있다. HTTP 프로토콜 표준에서 사용하는 Last-Modified 태그나 E-Tag를 이용하면 캐싱 구현이 가능하다.
4. Self-descriptiveness : 이는 단어 그대로 REST API 메시지만 보고도 무엇인지 쉽게 이해할 수 있는 자체 표현 구조로 되어 있다는 것을 말한다.
5. Client - Server 구조 : REST서버는 API를 제공하고 클라이언트는 사용자 인증이나 컨텍스트(세션, 로그인 정보)등을 직접 관리하는 구조로 각각의 역할이 확실히 구분되어있다. 때문에 클라이언트와 서버에서 개발해야 할 내용이 각각 명확해지고 서로 간에 의존성이 줄어들게 된다.
6. Hierarchical system : REST 서버는 다중 계층으로 구성될 수 있으며 보안, 로드 밸런싱, 암호화 계층을 추가해 구조상의 유연성을 둘 수 있고 PROXY, 게이트웨이 같은 네트워크 기반의 중간 매체를 사용할 수 있게 한다.

 

 

 

---

👍🏻 REST API 사용 시에 이점은?

 

► 통합성

  API는 새로운 애플리케이션을 기존 소프트웨어의 시스템과 통합하는데 사용될 수 있다. 각 기능을 처음부터 작성할 필요없이 기존 기능은 유지하고 새로운 기능만 추가하는 것이 가능하므로 개발의 속도가 빨라진다. REST API를 사용함으로써 기존 코드를 활용할 수 있다.

 

► 혁신성

  새로운 앱의 등장으로 산업이 변화될 수 있다. 기업은 서비스에 대해 신속한 대응과 배포를 지원해야 한다. REST API를 사용한다면 전체 코드를 다시 작성할 필요 없이 API 내에서 변경/추가하여 이를 가능하게 할 수 있다.

 

► 확장성

  REST API는 다양한 플랫폼에서도 서비스 대상의 요구 사항을 충족시켜줄 수 있다. 예를 들어 지도 API를 사용하여 웹 사이트, Android, iOS 등 어느 플랫폼에서도 지도 정보를 통합할 수도 있다. 또한 이러한 서비스에 해당하는 기업에서 제공하는 API 등을 활용하여 내부 데이터베이스에 유사한 액세스 권한을 부여할 수도 있다.

 

► 유지 관리 용이성

  앞서 API는 두 애플리케이션(시스템) 간의 소통 창구 역할을 한다고 하였다. API가 영향을 받지 않도록 각 시스템에서는 내부적으로 변경해야 한다. 이렇게 하면 후에 한 시스템의 코드 변경이 다른 시스템에게 영향을 미치지 않게 할 수 있다.

 

 

 

하지만 언제나 그렇듯 모든 것에는 좋은 점만 있지 않다. 단점들도 있기 마련이다.

 

 

1. 비표준 : 공식 문서가 없다. 즉, 공식적인 설계 가이드가 부재하여 참고한 내용에 따라 사람마다 다르게 해석하여 사용될 수가 있다. 이는 특징에서 양면성을 가지게 되는데 API 기능을 구현하고 제공하려면 개발 시간, 지속적인 유지 관리, 요구 사항 및 지원 제공 측면에서 경우에 따라 비용이 많이 발생할 수가 있다. 현재의 REST API 규칙들은 많은 사람들로부터 정당화된 약속들을 통해 구성되고 운용된다.
2. HTTP 방식의 제한 : REST API는 HTTP Method를 통해 URI를 표현한다. 다양한 환경에서 편하게 사용할 수 있다는 장점에 반해, Method의 형태가 제한적이기 때문에 복잡한 비즈니스에 적용할 수 없는 경우가 생기는 문제가 있다.
3. 보안성 : 이는 설계자에 따라 보안설정을 통해 다를 수 있지만 복잡한 구조를 가지고 있는 SOAP에 비해 직관적이고 간결한 통신방식으로 인해 보안성이 저해될 수 있다.

 

 

 

---

🤔 어느 방식이 더 좋을까? (feat. 마무리...) 

 

  대체적으로 웹 서비스(웹 애플리케이션)에서는 SOAP이 확실하게 좋은 방법이 아니라면 REST 방식의 API를 채택한다. 기업용 애플리케이션인 경우에는 보다 많은 리소스와 아주 엄격한 보안 그리고 여러 다양한 요구 사항들을 만족해야 하기 때문에 SOAP 방식을 택하는 경우가 많다고 한다.

 

 

보통의 웹 개발자라면 SOAP 방식을 마주하게 될일은 REST에 비해 확률히 현저히 낮지 않을까 생각한다.(개인적인 의견) 하지만 알고 사용하느냐 아니냐, 혹은 SOAP에 대해 조금이라도 이해하고 있느냐에 따라서 비교를 통해 REST를 사용하는데에 있어 좀 더 도움이 되지않을까 해서 포스팅해보았다.

 

 

 

 

이 포스팅은 여기서 마치고 다음 포스팅으로 Data Format을 갖고 돌아오겠다. 🫡

 

 

 

 

 

 

 

---

 

* 참고 문헌

API란 무엇인가요? - API 초보자를 위한 가이드 - AWS

혼공얄코

[Open API] SOAP 란?

SOAP REST 차이, 두 방식의 가장 큰 차이점은? - wishket

REST API 제대로 알고 사용하기 : NHN Cloud Meetup

REST API의 장점, 그리고 단점