[ Concept ] Web Service 개발 방법 및 개념

 

---

Web Service

 

Web Service란 World Wide Web(WWW)를 이용한 디바이스와 디바이스 간의 통신 서비스를 의미합니다.

네트워크 상에서 특정한 포트를 열어놓은 서버가 클라이언트의 요청을 받은 다음, HTML, JSON, XML, img 같은 웹 문서를 제공해 줍니다.

 

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

 

※ 키워드로 정리

 

• machine과 machine(application - application) 간의 상호작용을 위한 설계 
• 플랫폼의 독립적인 구조
• 애플리케이션 간의 네트워크를 통한 통신을 지원함으로써, 다양한 시스템과 애플리케이션 간의 통신을 지원함.

 

Web Application

 

Web Application은 서버에 저장되어 있고, 웹 브라우저를 통해 실행될 수 있는 프로그램입니다.(애플리케이션)

 

 

웹 애플리케이션을 실행 해 줄 수 있는 서버를 웹 애플리케이션 서버라고 부릅니다.

 

 

웹 서비스를 정의하기 위해서는 3가지가 필요합니다.

 

• Request/Response Format(문서 포맷)
• Request/Response Structure(문서 구조)
• EndPoint(URL...) 요청 서비스의 위치나 함수를 뜻하는 엔드포인트가 필요합니다.

 

※ 일반적으로 XML이나  JSON 포맷을 사용해서 개발하는데 문서량이 훨씬 적은 JSON이 대세가 되고 있습니다.

 

 

웹 서비스를 개발하기 위해 SAOP와  RESTful을 사용하는데, 개념은 다음과 같습니다.

 

SOAP(Simple Object Access Protocol)

 

SOAP란 Http, Https와 같은 프로토콜을 이용해서 xml 기반의 기반의 메시지를 컴퓨터 네트워크 상에서 전달할 수 있는 시스템을 의미합니다.

 

SOAP의 기본 구조는 Envelope, Header, Body로 되어 있으며, 해당 구조를 가진 문서로 전송하기 위한 방법과 상호 중립성 개념을 가지고 개발되어 있습니다. (HTTP, HTTPS 프로토콜 위에서 XML 메시지를 요청하고 응답받기 위한 서비스를 뜻합니다.)

 

※ 데이터를 전달하기 위해 우측 하단을 보면 앞/뒤로 부가적인 정보를 추가해주어야 한다.

 

SOAP의 장단점은 다음과 같습니다.

 

■장점

 

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

 

■단점

 

• XML 포맷은 태그 형태로 보내기 때문에 CORBA 같은 미들웨어 기술과 비교해서 상대적으로 느리다.
• 그에 따른 오버헤드가 심하다.
• 개발하기가 어렵다.

 

 

REST(REpresentational State Transfer)

 

REST는 자원의 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고받는 모든 것을 의미합니다.

 

• Resource(자원)의 Representaion(표현)에 의한 상태 전달
• HTTP Method를 통해 Resource를 처리하기 위한 아키텍처

여기서 Resource는 "자원"이라고 말하며, 컴퓨터에 저장되어 있는 파일, DB에 저장되어 있는 데이터 등등 모든 자원들을 각각 고유하게 표현하기 위한 이름으로써 구분한 다음에 그 자원이 가지고 있는 상태 즉, 정보값을 주고받는 서비스 형태입니다.

 

■장점

 

• HTTP 프로토콜의 인프라를 그대로 사용하므로 REST API 사용을 위한 별도의 인프라를 구출할 필요가 없다.
• HTTP 프로토콜의 표준을 최대한 활용하여 여러 추가적인 장점을 함께 가져갈 수 있게 해 준다.
• HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하다.
• REST API 메시지가 의도하는 바를 명확하게 나타내므로 의도하는 바를 쉽게 파악할 수 있다.
• 여러 가지 서비스 디자인에서 생길 수 있는 문제를 최소화한다.
• 서버와 클라이언트의 역할을 명확하게 분리한다.

 

■단점

 

• 표준이 존재하지 않는다.
• 사용할 수 있는 메서드가 4가지 밖에 없다.

• HTTP Method 형태가 제한적이다.

• 브라우저를 통해 테스트할 일이 많은 서비스라면 쉽게 고칠 수 있는 URL보다 Header 값이 왠지 더 어렵게 느껴진다.
• 구형 브라우저가 아직 제대로 지원해주지 못하는 부분이 존재한다.

• PUT, DELETE를 사용하지 못하는 점
• pushState를 지원하지 않는 점

 

 

REST가 필요한 이유는 애플리케이션을 분리 및 통합을 할 수 있고, 다양한 클라이언트를 생성할 수 있습니다.

 

최근 서버 프로그램은 다양한 브라우저와 안드로이드 폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야 하므로 REST가 필요합니다.

 

이러한 멀티 플랫폼에 대한 지원을 위해 서비스 자원에 대한 아키텍처를 세우고 이용하는 방법을 모색한 결과, REST에 관심을 가지게 되었습니다.

 

 REST API

 

REST API는 REST Service를 제공해 주는 Application Programing Interface를 뜻하며, REST API를 제공하는 웹 서비스를 RESTful이라고 합니다.

 

RESTful 서비스를 사용하기 위해서는 HTTP 프로토콜을 사용할 수 있는 애플리케이션이 필요하게 되는데 일반적으론 인터넷 웹 브라우저가 많이 사용됩니다.

 

RESTful 서브 시에 의해서 제공되는 자원들은 각각 고유한 주소값을 가지고 있는데, 이러한 주소값을 URI(Unitform Resource Identifier)라고 합니다.

 

이러한 주소값은 고유하고 유니크해야 하며, 리소스를 요청하거나 응답할 땐 XML, HTML, JSON과 같은 문서 포맷이 사용되고 있습니다.

 

SOAP vs REST 선택 기준

 

1. 접근제한성이나 시스템 아키텍처의 구조에 맞는 것으로 선택
2. 사용되는 데이터 문서 포맷의 종류에 따라 선택
3. 서비스를 정의하는 방법
4. 전송되는 방법과 전송규약
5. 구현 방법(개발의 용의성)

 

---

마치며

 

오늘은 Web Service에 대해서 알아보았습니다.

깊게 파고 들면 정말 끝도 없이 나오는데, 포스팅을 하면서 이해할 수 있어서 다행입니다..^^

다음 포스팅에서 뵙겠습니다.