[기본] 웹서비스 그리고 RESTful, SOAP 란?

1. 웹서 비스( WebService ) 란?



서로 다른 컴퓨팅 환경에서 사용되는 모든 애플리케이션들이 직접 소통하고 실행될 수 있도록 동적 시스템 환경을 구현해 주는 소프트웨어 컴포넌트


단순 객체 접근 프로토콜(SOAP), 웹 서비스 기술 언어(WSDL), 전역 비즈니스 레지스트리(UDDI) 등의 표준 기술을 사용하여 네트워크에 연결된 다른 컴퓨터 간의 분산 컴퓨팅을 지원하는 소프트웨어 및 기술들이다.


웹 서비스는 논리적 응용 프로그램의 단위로 데이터와 서비스를 다른 응용 프로그램에 제공하고, 응용 프로그램의 작성 시 HTTP, XML, SOAP와 같은 표준화된 웹 프로토콜과 데이터 형식을 사용함으로써 운영 체계(OS) 등 특정 플랫폼과 상관없이 모든 컴퓨터 간 원활한 데이터의 흐름을 보장해 준다.

요약하자면, 웹서비스란 네트워크 상에서 서로 다른 종류의 컴퓨터들 간에 상호 작용을 하기 위한 소프트웨어 시스템으로 웹(World Wide Web)이 사람과 컴퓨터 간의 상호작용을 위한 시스템이라면 웹 서비스는 컴퓨터와 컴퓨터 간의 상호 작용을 위한 시스템이다.

2. REST( RESTful ) 란?




REpresentational State Transfer, REST




REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식이다. 이 용어는 로이 필딩(Roy Fielding)의 2000년 박사학위 논문에서 소개되었다. 필딩은 HTTP의 주요 저자 중 한 사람이다. 이 개념은 네트워킹 문화에 널리 퍼졌다.




엄격한 의미로 REST는 네트워크 아키텍처 원리의 모음이다. 여기서 ‘네트워크 아키텍처 원리’란 자원을 정의하고 자원에 대한 주소를 지정하는 방법 전반을 일컫는다. 간단한 의미로는, 웹 상의 자료를 HTTP위에서 SOAP이나 쿠키를 통한 세션 트랙킹 같은 별도의 전송 계층 없이 전송하기 위한 아주 간단한 인터페이스를 말한다. 이 두 가지의 의미는 겹치는 부분과 충돌되는 부분이 있다. 필딩의 REST 아키텍처 형식을 따르면 HTTP나 WWW이 아닌 아주 커다란 소프트웨어 시스템을 설계하는 것도 가능하다. 또한, 리모트 프로시저 콜 대신에 간단한 XML과 HTTP 인터페이스를 이용해 설계하는 것도 가능하다. 출처: 위키피디아




REST 는 한 마디로 정확히 정의하기 어려운 개념인 것 같다. 부분 부분을 하나 하나 살펴보면서 이해해보도록 하자.




2. 1 REST의 기본 구조




REST는 다음의 세 가지 요소로 구성된다.



■ 자원 (Resource) - URI
■ 행위 (Verb) - HTTP Method
■ 표현 (Representation)

- REST는 제어할 자원을 표시한 URI 로 수행할 행위인 HTTP Method 를 보내어 그 결과를 표현 한다.




2. 2 URI




Uniform Resource Identifier, URI




통합 자원 식별자(Uniform Resource Identifier, URI)는 인터넷에 있는 자원을 나타내는 유일한 주소이다. URI의 존재는 인터넷에서 요구되는 기본조건으로서 인터넷 프로토콜에 항상 붙어 다닌다. 출처: 위키피디아




URI 는 웹 상에 존재하는 어떤 자원의 주소이다. 경기도 안산시 상록구 사동이라는 주소를 가지는 곳은 지구상에서 단 한 곳인 것 처럼 URI는 웹 상에 존재하는 어떤 유일한 자원을 가리키는 주소이다.

예를 들어 지금 이 페이지의 URI는

http://helloworld-88.tistory.com/62?category=667460

이며 어느 장소에서든 이 URI로 접속하면 지금 보고 있는 이 블로그 포스트로 오게 된다.




2. 3 URI 와 URL 의 차이




URI 는 Uniform Resource Identifier 이고,

URL 은 Uniform Resource Locator 이다.




즉, URL은 어떤 자원의 위치를 나타내고 URI는 어떤 자원을 식별하기까지 한다.

URL은 URI에 포함되는 하위 개념이다.

https://dark9924.github.io/Webfoot-octopus/index.html

위 주소는 dark9924.github.io 라는 서버의 Webfoot-octopus 디렉토리 안에 있는 index.html 파일을 나타내는 URL이다.

http://helloworld-88.tistory.com/62?category=667460

위의 주소에서 URL은 http://helloworld-88.tistory.com/62 까지 이다.

?category= 라는 식별자 뒤에 무엇이 오느냐에 따라 나타나는 결과가 달라지게 되기 때문에 ?category=667460 까지 포함한 주소는 URI이다.




요즘은 점점 URI를 더 많이 쓰는 추세라고 한다. URI가 더 큰 개념이기 때문에 잘 모르겠으면 URI라고 하면 된다고 한다.




2. 4 REST에서의 URI




RESTful한 URI는 반드시 자원을 가리켜야 한다.

처음 장고를 배울 때를 생각해보자. 예를 들어 1번 글 을 삭제하는 기능을 만들 때 URI 패턴을 아래와 같이 설정해주었던 것을 기억해보자.

post/delete/1

위 URI로 접속하면 1번 포스트가 삭제된다. 이러한 URI 설정은 REST를 제대로 적용하지 않은 URI이다.

RESTful한 URI는 정보의 자원만을 나타내야하며 어떤 행위가 포함되지 않도록 해야한다.

post/1

위와 같은 URI는 1번 글 자원을 명확히 나타내는 URI이다. 이 자원에 대해 행할 행위는 URI에 포함시키는 것이 아닌 HTTP Method 를 통해 수행하게 된다.




2. 5 HTTP Method




REST에서는 어떤 자원에 행할 수 있는 행위를 네 가지로 나타내며 이를 CRUD 라고 한다.

CRUD는 Create, Read (Retrieve), Update, Delete 의 첫 글자를 각각 따온 것이다.

CRUD는 각각 HTTP Method 의 POST, GET, PUT, DELETE 에 대응된다.




POST POST를 통해 해당 URI를 요청하면 리소스를 생성한다.

GET GET를 통해 해당 리소스를 조회하고 해당 도큐먼트에 대한 자세한 정보를 가져온다.

PUT PUT를 통해 해당 리소스를 수정한다.

DELETE DELETE를 통해 리소스를 삭제한다.

METHOD	역할
POST	해당 URI 를 요청하면 리소스를 생성한다.
GET	해당 리소스를 조회하고 해당 도큐먼트에 대한 자세한 정보를 가져온다.
PUT	해당 리소스를 수정한다.
DELETE	리소스를 삭제한다.

지금까지 배운 장고에서는 GET과 POST 방식의 요청에 대해서만 다루었다.

그렇기 때문에 post/delete/1 이나 post/create/1 등 과 같은 URI 패턴을 새로 만들어 포스트를 삭제하거나 생성할 수 밖에 없었다.

이제 REST를 배우면 좀 더 명확하고 깔끔한 URI 설계가 가능하게 될 것이다.

예를 들어 1번 글 을 삭제하려 할 때 기존에는 다음과 같이 post/delete/1 라는 주소로 POST 요청을 보내어 글을 삭제하였다.

POST post/delete/1

REST에서는 똑같은 작업을 아래와 같이 수행한다.

DELETE post/1

post/1 이라는 자원으로 DELETE 요청을 보내는 것이다. 제어하려는 자원과 행하려는 행위가 명확히 구분되어 어떤 작업을 하려는 건지 직관적으로 이해할 수 있게 되었다.




2. 6 Representation




자원의 URI에 특정 행위를 요청하면 그 결과로 Representation 을 응답 받는다.

어떤 자원의 Representation은 html, xml, text, json, rss 등 다양한 형태로 표현될 수 있다.

예를 들어 1번 글 의 내용을 확인하는 요청을 아래와 같이 보냈다고 생각해보자.

GET post/1

그 결과로 돌려받는 Representation은 아래와 같은 json 파일이 될 수 있을 것이다.

[     "post":{         "id": 1,         "title": "First Post",         "content": "Hello! This is the First Post!"     } ]

3. SOAP 란?



Simple Object Access Protocol, REST


SOAP(Simple Object Access Protocol)은 일반적으로 널리 알려진 HTTP, HTTPS, SMTP 등을 사용하여 XML 기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 형태의 프로토콜이다. 즉, 다른 컴퓨터에 있는 데이터나 서비스를 호출하기 위한 통신규약(Protocol)으로 SOAP 는 웹 서비스(Web Service)에서 기본적인 메시지를 전달하는 기반이 된다. SOAP에는 몇가지 형태의 메시지 패턴이 있지만, 보통의 경우 원격 프로시져 호출(Remote Procedure Call:RPC) 패턴으로, 네트워크 노드(클라이언트)에서 다른 쪽 노드(서버)쪽으로 메시지를 요청 하고, 서버는 메시지를 즉시 응답하게 된다. SOAP는 XML-RPC와 WDDX에서 envelope/header/body로 이루어진 구조와 전송(transport)와 상호 중립성(interaction neutrality)의 개념을 가져왔다.


SOAP은 XML을 근간으로 헤더와 바디를 조합하는 디자인 패턴으로 설계되어 있다. 「헤더」는 선택사항으로 반복이나 보안 및 트랜젝션을 정보로 하는 메타 정보를 가지고 있다. 「바디」부분은 주요한 정보인 정보를 가지고 있다.

3. 1 SOAP 장점 및 단점


■ 장점


- SOAP를 사용한 HTTP는 기존 원격 기술들에 비해서 프록시와 방화벽에 구애받지 않고 쉽게 통신 가능하다.
- SOAP는 융통성있게도 각각 다른 트랜스포트 프로토콜들의 사용을 허용하고 있다.
- 표준 스택에서는 트랜스 포트 프로토콜로 HTTP를 사용하지만, 다른 프로토콜 역시 사용가능 하다.
- SOAP는 플랫폼 독립적이다.
- SOAP는 프로그래밍 언어에 독립적이다.
- SOAP 간단하고, 확장가능하다.


■ 단점


XML 포맷은 태그 형태로 보내기 때문에 CORBA같은 미들웨어 기술과 비교해서 상대적으로 느리다. 이것은 전송할 메시지가 적을때에는 문제 되지 않을 수 있다. 성능을 향상시키기 위해서 바이너리 객체를 포함시킨 특별한 경우의 XML(바이너리 XML을 말하는듯)로 메시지 전송 최적화 메커니즘(Message Transmission Optimization Mechanism; MTOM)이 나왔다. 게다가 일반적인 XML의 성능을 향상시키기 위해, VTD-XML과 같은 emerging non-extractiv XML 처리 모델이 있다.


3. 2 SOAP SAMPLE

<SOAP-ENV:Envelope      xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">          <SOAP-ENV:Body>              <getProductDetails xmlns="http://warehouse.example.com/ws">                 <productId>827635</productId>             </getProductDetails>          </SOAP-ENV:Body>      </SOAP-ENV:Envelope>

4. RESTful 과 SOAP 비교

		SOAP 기반 웹서비스	RESTful 웹서비스
배경 및 현황		▶ 기업을 위한 비즈니스 응용에서부터 출발 ▶ IBM, Oracle 등을 선두로 하는 웹서버 벤더에서 주창 ▶ SOA의 서비스는 대부분이 비즈니스 컴포넌트로서의 의미를 가짐	▶ WEB 2.0 은 서비스 애플리케이션에서부터 시작 ▶ 구글, 아마존과 같은 인테넷 서비스에서 주창 ▶ 맵이나 뉴스, 가젯 등과 같이 UI 성격을 갖는 서비스가 대다수임
특징		▶ The Machine-Readable Web: 사람보다는 기계가 해석할 수 있는 웹 ▶ Stateful: 오퍼레이션 중 서비스 상태가 일관되게 유지, 관리되어야 함 ▶ 엄격한 문법 검사, 서비스 계약에 충실 ▶ 웹 서버 등 웹서비스 개발 환경이 지원되어야 함	▶ The Human-Readable Web: 사람이 해석할 수 있는 웹 ▶ Stateless: 오퍼레이션 중 서비스/리소스의 상태를 관리하지 않음( HTTP의 기본 메커니즘 ), 필요한 경우에 직접 관리해야 함 ▶ 기본 XML 만으로 서비스 개발 가능 ▶ 별도의 개발 환경 지원이 필요 없음
적용  기술	전달 메커니즘	Remote Proceddure Call	Publish/Syndicate Pattern
	전달 프로토콜	SOAP/HTTP, SMTP	HTTP
	서비스 명세	WSDL	WADL, XML, JSON, hREST ( 시맨틱 REST ) 등
	서비스 레지스트리	UDDI	없음
	필요 스택	W3C 의 WS-* 스택 (WS-addressing, WS-security 등)	없음
주요 적용 분야		트랜잭션 프로세싱	데이터와 UI 프로세싱
현재의 문제점		어려운 사용법, 무거운 프로토콜	표준의 부재, 관리가 어려움

참고

http://mygumi.tistory.com/55

http://trudger.tistory.com/entry/SOAP-%EC%99%80-REST

https://nachwon.github.io/rest-1/

http://lambdaexp.tistory.com/39

http://meetup.toast.com/posts/92

http://bcho.tistory.com/953