[SOAP]Web Service (SOAP, REST)

업무를 보다 보면 고객사 시스템과의 데이터 연동 프로그램을 개발할 일이 종종 있다. 최근에 많이 사용되는 방법은 SOAP 프로토콜을 이용해 웹서비스로 인터페이스 하는 방법이다.

웹서비스란 무엇인가, SOAP와 REST의 차이에 대해서 정리해본 후, SOAP 프로젝트를 개발할 수 있는 방법들에 대해 시리즈로 정리할 생각이다.

 

웹 서비스

---

웹서비스는 서비스 지향적 분산 컴퓨팅 기술의 일종으로, 서로 다른 기종의 정보시스템을 통합 및 연계해 인터넷을 통해 다른 시스템에 존재하는 응용 소프트웨어도 자신의 것처럼 호출해 이용할 수 있는 기술이다.

최근 들어 웹서비스는 SOAP 기반의 웹서비스와 REST 기반의 웹서비스로 양분화되어 제공되고 있다. 서비스 인터페이스를 구현 로직으로부터 분리하는 웹서비스의 기본 개념을 따르면서 SOAP 기반의 웹서비스는 비즈니스 플로우 처리를 위한 서비스 상호 연동에 주로 이용되고, REST 웹서비스는 데이터 접근에 주로 이용된다.

 

💡 Web Service VS World Wide Web (W3)

: 월드 와이드 웹은 사람과 컴퓨터 간의 상호작용을 위한 시스템인데 반해, 웹 서비스는 컴퓨터와 컴퓨터 간의 상호작용을 위한 시스템이다.

 

SOAP? REST?

---

SOAP와 REST는 "웹 서비스에 액세스 하는 방법에는 무엇이 있습니까?"라는 질문에 대한 답변일 뿐이다.

SOAP와 REST 중 사용할 방식을 결정하기 위해서는 본인이 개발할 프로그램의 요구사항을 잘 충족하는 웹서비스가 무엇인지에 초점을 맞춰야 한다.

 

1. SOAP의 특성

• 서비스의 기술문서(WSDL)를 매개로 서비스 능력을 개방하고자 한 기술이다.
• 언어, 플랫폼 및 전송 프로토콜에 독립적 (REST는 HTTP 사용 필요)
• 분산 엔터프라이즈 환경에서 잘 작동(REST는 직접적인 지점 간 통신을 가정)
• 표준화
• 상당한 WS* 표준 형식의 사전 구축 확장성
• 내장된 오류 처리
• 특정 언어 제품과 함께 사용되는 경우 자동화

2. REST의 특성

• URI를 기반으로 리소스를 개방하고자 하는 기술이다.
• REST는 대부분 사용하기 쉽고 더 유연하다. ⇒ 학습 곡선이 더 작음
• 웹 서비스와 상호 작용하는 데 값비싼 도구가 필요하지 않다.
• 효율적 (SOAP은 모든 메시지에 XML을 사용하고 REST는 더 작은 메시지 형식을 사용할 수 있음)
• 빠름 (광범위한 처리가 필요 없음)

 

SOAP (Simple Object Access Protocol)

---

분산되어 있는 콘텐츠를 추상적인 서비스 형태로 개방하여 표준화된 형태로 공유하는 기술로써 SOA 개념을 실현하기 위한 대표적 표준 프로토콜이다. 이 기술은 이기종 플랫폼 위에 구축된 시스템들 간의 연동을 목적으로, 상호 이해 가능한 포맷의 메세지를 SOAP로 송수신함으로써 원격지에 있는 서비스 객체나 API를 자유롭게 사용하고자 하는 기업의 요구에서 시작되었다.

SOAP는 특정 분산 기술 또는 플랫폼에 의존하지 않고 분산 객체를 액세스 할 수 있는 프로토콜로써 HTTP상에서 전송된다. 모든 SOAP 메시지는 Envelope, Header, Body로 구성된 하나의 XML 문서로 표현되는데, 이러한 복잡한 구성으로 인해 HTTP상에서 전달되기 무겁고, 메시지 인코딩/디코딩 과정 등 웹서비스 개발의 난도가 높아 개발 환경의 지원이 필요하다.

웹서비스 내의 모든 데이터는 XML로 표현되고, 그 데이터들과 이를 다룰 수 있는 오퍼레이션들이 WSDL로 정의되면 UDDI라는 전역적 서비스 저장소에 등록(publish)되어 누구라도 서비스를 찾을 수 있도록 공개된다. 공개된 웹서비스가 이용될 때, 서비스 요청자와 서비스 제공자 간에 SOAP를 이용해 서비스를 호출하고 결과를 돌려받게 된다.

 

1. SOA

• 서비스 지향 아키텍처(Service Oriented Architecture)는 대규모 컴퓨터 시스템을 구축할 때의 개념으로 업무상에 일 처리에 해당하는 소프트웨어 기능을 서비스로 판단하여 그 서비스를 네트워크 상에 연동하여 시스템 전체를 구축해 나가는 방법론이다.

2. UDDI

• Universal Description, Discovery and Integration.
• UDDI 스펙은 기업이 글로벌 비즈니스 레지스트리에 정보를 공유하고 레지스트리에서 서비스를 발견하며, 인터넷을 통해 상호작용하는 방법을 정의할 수 있도록 하는 개방형의 플랫폼 독립적 표준을 정의한다.
• JEUS에서의 UDDI: https://technet.tmaxsoft.com/upload/download/online/jeus/pver-20140827-000001/web-service/chapter_uddi.html

3. WSIL

• Web Services Inspection Language
• UDDI를 보충하는 동시에 UDDI를 대체할 수 있는 서비스 발견 메커니즘이다. UDDI를 사용하여 웹 서비스를 발견하는 경우 중앙 레지스트리로 이동하는 반면, WSIL을 사용하면 서비스 제공자로 직접 이동하여 제공되는 서비스를 요청할 수 있다.

4. WSDL

• WSDL은 특정 비즈니스가 제공하는 서비스를 요청자들이 전자적으로 접근하여 이용할 수 있도록 표준 형태로 정의하는 XML기반의 언어이다. 여기에는 웹서비스 이름과 주소(URL), 인터페이스, SOAP 메시지 인코딩 방식, SOAP전달을 위한 전송 프로토콜 등이 기술된다. WSDL은 W3C에서 표준화되고 있으며, 현재 산업계에서는 WSDL 1.1과 2.0을 지원하고 있다.
• 특정 IDE는 WSDL을 참조하여 서비스를 생성할 때 생성 프로세스를 완전히 자동화 할 수 있다. 따라서 SOAP 사용의 어려움은 사용하는 언어나 플랫폼에 따라 크게 달라질 수 있다.
• WSDL을 통해 서비스 제공자는 아래 웹서비스 특성을 지정할 수 있다.
• WSDL 네트워크 서비스 정의 요소
  • -유형: 일부 유형 시스템을 사용하는 데이터 유형 정의를 위한 컨테이너(예: XSD).
  • 메시지: 통신 중인 데이터의 유형 지정된 추상 정의.
  • 오퍼레이션: 서비스가 지원하는 조치의 추상 설명.
  • 포트 유형: 하나 이상의 엔드포인트에서 지원되는 오퍼레이션의 추상 세트.
  • 바인딩: 특정 포트 유형의 구체적 프로토콜 및 데이터 형식 스펙. 바인딩은 일반적으로 SOAP이며, 사용되는 인코딩 및 데이터 형식 규정은 일반적으로 리터럴이다.
  • 포트: 바인딩 및 네트워크 주소의 결합으로 정의되는 단일 엔드포인트.
  • 서비스: 관련 엔드포인트의 콜렉션.

5. SOAP, UDDI, WSIL, WSDL 간의 관계

• 서비스 제공자는 웹 서비스를 호스트 하여 SOAP/HTTP 또는 SOAP/JMS와 같은 프로토콜을 사용하여 액세스 할 수 있게 한다. 웹 서비스는 제공자의 서버 또는 특수 저장소에 저장된 WSDL 문서로 설명한다. UDDI 비즈니스 레지스트리 및 WSIL 문서가 WSDL 문서를 참조할 수 있는데, 여기에는 웹 서비스의 WSDL 파일에 대한 포인터가 포함되어 있다.

 

 

REST

---

웹의 창시자 중 한 사람인 Roy Fielding이 현재의 웹 아키텍처가 웹의 본래 설계의 우수성을 활용하지 못하므로 웹의 장점을 최대한 활용할 수 있는 네트워크 기반의 아키텍처를 제안했는데, 이것이 REST이다. REST는 부수적인 레이어나 세션 관리를 추가하지 않고도 HTTP 프로토콜로 데이터를 전달하는 프레임워크이다. 최근 들어 REST는 웹에 개방된 리소스들을 원격에서 또는 지역적으로 쉽게 이용하려는 웹 응용에 정착하게 되었고, REST 아키텍처 스타일에 따라 정의되고 이용되는 서비스나 응용을 RESTful 웹서비스라 한다.

"리소스" 란 REST 아키텍처의 핵심 요소로써 웹사이트, 블로그, 이미지, 음악, 이용자, 검색 결과 등 웹에서 다른 이들과 공유하고자 개방된 모든 자원을 의미한다. REST 구조에서의 리소스는 그들의 고유한 URI를 가지며, HTTP의 기본 메서드인 GET/PUT/POST/DELETE만으로 접근할 수 있다.

HTTP 기본 메서드로 전달되는 리소스는 다양한 방식으로 표현되는데, XML, JSON, HTML, 텍스트, 이미지 등이 가능하며 클라이언트에서 원하는 형식으로 표현하면 서버에서 이를 처리하게 된다. 리소스의 다양한 표현 방식은 HTTP의 accept헤더 값 또는 URI 파라미터로 지정하면 된다.

요청 데이터를 XML로 꼭 감싸야만 하는 기존 SOAP의 단점 때문에, SOAP의 불편함을 해소시킬 대안으로 많이 사용되고 있는 추세이다.

 

1. ROA

• 자원 지향 아키텍처(Resource Oriented Architecture)는 서비스를 제공하는 시스템의 리소스가 중요시되는 구조이다. ROA는 서비스 중심의 SOA에 대응되는 개념으로 일컬어지고 있다.

2. REST API, RESTful

• REST는 아키텍처를 정의하는 것일 뿐, 실질적인 구현이 아닌 설계적 지침이다. 이 REST라는 지침을 따라 만든 서비스가 REST API이며, 이렇게 필딩의 REST 원리를 따르는 시스템은 종종 RESTful이란 용어로 지칭된다.
• REST API를 구현할 때는 기본 원칙과 지침이 따라져야 하는데, 실제로 REST API라고 제공되는 서비스를 보면 RESTful 하지 않은 경우가 대다수이다.

3. REST 인터페이스의 원칙에 대한 가이드

• 자원의 식별 요청: 내에 기술된 개별 자원을 식별할 수 있어야 한다. 웹 기반의 REST 시스템에서의 URI의 사용을 예로 들 수 있다. 자원 그 자체는 클라이언트가 받는 문서와는 개념적으로 분리되어 있다. 예를 들어, 서버는 데이터베이스 내부의 자료를 직접 전송하는 대신, 데이터베이스 레코드를 HTML, XML이나 JSON 등의 형식으로 전송한다.
• 메시지를 통한 리소스의 조작: 클라이언트가 어떤 자원을 지칭하는 메시지와 특정 메타데이터만 가지고 있다면 이것으로 서버 상의 해당 자원을 변경·삭제할 수 있는 충분한 정보를 가지고 있는 것이다.
• 자기 서술적 메시지: 각 메시지는 자신을 어떻게 처리해야 하는지에 대한 충분한 정보를 포함해야 한다. 예를 들어 MIME type과 같은 인터넷 미디어 타입을 전달한다면, 그 메시지에는 어떤 파서를 이용해야 하는지에 대한 정보도 포함해야 한다. 미디어 타입만 가지고도, 클라이언트는 어떻게 그 내용을 처리해야 할지 알 수 있어야 한다. 메시지를 이해하기 위해 그 내용까지 살펴봐야 한다면, 그 메시지는 자기 서술적이 아니다. 예를 들어, 단순히 "application/xml"이라는 미디어 타입은, 실제 내용을 다운로드 받지 않으면 그 메시지만 가지고는 무엇을 해야 할지에 대해 충분히 알려주지 못한다.
• 애플리케이션의 상태에 대한 엔진으로써 하이퍼미디어: 만약에 클라이언트가 관련된 리소스에 접근하기를 원한다면, 리턴되는 지시자에서 구별될 수 있어야 한다. 충분한 콘텍스트 속에서의 URI를 제공해주는 하이퍼텍스트 링크의 예를 들 수 있겠다.
• 당신의 API가 Restful 하지 않은 5가지 증거 https://beyondj2ee.wordpress.com/2013/03/21/%EB%8B%B9%EC%8B%A0%EC%9D%98-api%EA%B0%80-restful-%ED%95%98%EC%A7%80-%EC%95%8A%EC%9D%80-5%EA%B0%80%EC%A7%80-%EC%A6%9D%EA%B1%B0/

 

 

 

[참고 문서들]

https://ko.wikipedia.org/wiki/%EC%9B%B9_%EC%84%9C%EB%B9%84%EC%8A%A4

https://www.redhat.com/ko/topics/integration/whats-the-difference-between-soap-rest

https://www.ibm.com/docs/ko/rsas/7.5.0?topic=overview-web-services-standards 

https://mygumi.tistory.com/55