본문

SOAP과 Restful

반응형

SOAP(Simple Object Access Protocol)

일반적으로 널리 알려진 HTTP, HTTPS, SMTP 등을 통해 XML 기반의 메세지를 네트워크 상에서 교환하는 프로토콜

 

왜 SOAP를 사용하는가?

-. 기존 원격 기술들에 비해서 Proxy와 방화벽에 구애받지 않고 쉽게 통신 가능
-. 플랫폼과 프로그래밍 언어에 독립적
-. 웹 서비스를 제공하기 위한 표준(WSDL, UDDI, WS-*)이 잘 정립되어 있음
-. 에러 처리에 대한 내용이 기본으로 내장
-. 분산 환경에 적합

 

왜 SOAP를 사용하지 않는가?

-. 복잡한 구조로 인해 오버헤드가 있으며, 이는 SOAP의 확장을 저해하고 있음
-. REST에 비해 상대적으로 무겁고 속도도 느리다
-. 개발 난이도가 높아 개발 환경의 지원이 필요하다 

what is the 오버헤드: https://terms.naver.com/entry.nhn?docId=2829829&cid=40942&categoryId=32828

 

SOAP 아키텍처

UDDI 레지스트리를 통해 웹서비스를 등록(Publish)하고, 탐색(Find)하고, 바인딩(Bind)하여 사용

 

SOAP 프로세스

서비스 요청자가 SOAP로 인코딩하여 웹 서비스 요청을 서비스 제공자에게 전달
서비스 제공자는 이를 디코딩하여 적절한 서비스 로직을 수행시켜서 결과를 얻고, 그 결과를 다시 SOAP로 인코딩하여 반환

 

SOAP 메세지 구조

 

SOAP API 예제 - Request/Reponse Format

 


REST(REpresentational State Transfer)

 

HTTP를 통해 세션 트래킹 같은 부가적인 전송 레이어 없이, 전송하기 위한 아주 간단한 인터페이스
HTTP등의 기본 개념에 충실히 따르는 웹 서비스

 

왜 REST를 사용하는가?

-. 플랫폼과 프로그래밍 언어에 독립적(SOAP과 동일)
-. SOAP보다 개발하기 단순하므로 러닝커브가 작고 도구가 거의 필요없음
-. 간결하므로 추가적인 메세징 계층이 없음


왜 REST를 사용하지 않는가?

-. point-to-point 통신 모델을 가정하므로 둘 이상으로 상호작용하는 분산환경에는 유용하지 않다
-. 보안, 정책 등에 대한 표준이 없다
-. HTTP 통신 모델만 지원한다

 

REST 아키텍처

리소스를 등록하고 저장해두는 중간 매체 없이 리소스 제공자가 직접 리소스 요청자에게 제공


REST 프로세스

기본 HTTP 프로토콜의 메소드 GET/PUT/POST/DELETE를 이용하여 서비스 제공자에게 서비스를 요청

서비스 제공자는 다양한 형태로 표현된 (JSON, XML, RSS등) 리소스를 반환

 

Restful API 예제 - JSON Request


표준이냐 간결함이냐

표준의 힘은 위에 이미 언급을 하였다. 그러나 간결함의 힘도 무시할 수 없다.

 

단순함 간결함은 직관적이며 쉽게 개발하거나 사용할 수 있어 기술의 전파 속도가 굉장히 빠르다는 것이다.

단순함이나 간결함을 가진 기술은 굳이 따로 배우지 않더라도 바로 사용할 수 있는 힘이 있다.

따라서 아키텍처나 설계에 있어 단순함, 간결함을 매우 강조하는 이유가 여기에 있다.

 

SOAP은 통신에 중립적인 구조로 설계되어 있어 부수적인 메시징 정보를 또 포함하고 있다.

HTTP를 이용하여 SOAP을 이용할 경우 이미 HTTP에 포함된 메시징 정보(URL 또는 각종 헤더)에 또 메시징 정보를 포함한다.

이는 편지를 붙이기 위해 주소를 적은 편지봉투를 다시 조금 더 큰 편지봉투에 넣어 보내는 것과 같은 꼴이 된다.

 

SOAP이 HTTP를 이용하지 않고 다른 프로토콜로 구현한다면 복잡하고 장황한 스팩이 나름대로 의미가 있겠지만 HTTP를 이용한 SOAP 통신이 주를 이루고 있어 위와 같은 상황이 되는게 사실이다.

 

그러나 SOAP을 무시할 수 없는게 표준이라는 힘에 의해 많은 개발도구들이 SOAP을 지원하여 SOAP을 이용하면 특별한 노력없이 바로 연동이 가능한 점이 있다.

 

이렇게 표준의 힘을 사용할 것인가 아니면 간결함의 힘에 의지할 것인가에 대한 고민이 있고 이에 대한 논의는 계속되는 상황이다.

 

트랜드

물론 두 가지의 기술 중에 한 가지만 고집하고 사용할 필요는 없다. 여력이 되는데로 모두 배우고 상황에 맞춰 선택하여 사용해도 될 것이다. 그러나 앞으로 어떤 기술이 주를 이룰지 예측해보는 것은 가치가 있는 일이다.

 

여러 웹 사이트에서 자료를 수집해 보니 역시 단순한 기술의 전파력이 무섭다는 것을 알 수 있다.

 

아마존은 SOAP과 REST 서비스 모두 제공하는데 85% 정도가 REST 서비스를 사용하는 것으로 알려졌다. (2003년)

Google은 SOAP 기술에 대해 그리 좋게 보지 않고 있으며 더 이상 SOAP API에 대한 지원을 하지 않는다. (http://radar.oreilly.com/archives/2006/12/google-depreciates-SOAP-API.html)

야후는 현재까지 SOAP API를 제공할 계획이 없다. (http://developer.yahoo.com/faq/#soap)

 

 

 


from https://greatkim91.tistory.com/79

from https://deepwelloper.tistory.com/89

반응형

공유

댓글