SOAP과 REST

 

 

 

 

 

Web Application에서 Web Service로 전달되는 요청 정보를 클라이언트의 Request라고 하고, Web Service에서 처리된 결과를 다시 클라이언트나 Web Application으로 반환시켜 주는 것을 Response라고 함. 입력과 출력의 개념으로 본다면 Request가 Input, Response가 Output인 것.

 

 

Web Service를 개발하기 위해서는 서비스에 대한 정의가 필요한데 이를 정의하기 위해서는 어떠한 요청 정보가 있는지, 그리고 그러한 Request와 Response가 전달되는 데이터 포맷을 어떻게 할 것인지에 대한 정의가 선행되어야 함. 또한 Request와 Response의 구조, 요청하려 하는 서비스의 위치, 어떠한 방법으로 요청해야 하는지에 대한 정보를 위해 서비스에 대한 endpoint 정보도 필요함.

Request와 Response의 포맷은 일반적으로 XML과 JSON을 많이 사용하는데 최근에는 XML보다 문서의 양이 훨씬 적은 JSON 포맷을 많이 사용하는 추세.

 

 

cf) 아래 경로에서는 JSON 포맷에 대한 정의, 어떻게 데이터 구조를 나타낼 수 있는지에 대한 명세를 확인할 수 있음. 

https://www.json.org/json-ko.html

JSON

 

 

 

Web Service 의 요청 정보를 전달하는 쪽을 서비스에 대한 소비자 또는 클라이언트라고 하고, 이러한 클라이언트의 요청을 처리해 주는 쪽을 서비스에 대한 제공자 또는 서버라고 함.

 

이러한 Web Service를 개발하기 위해 많이 사용되는 기술 중 SOAP과 REST 방식이 있음. 물론 이건 어디까지나 서비스에서 제공하려 하는 비즈니스 로직을 위해 사용되는 것이고, IT 개발에서는 이를 애플리케이션 로직, 비즈니스 로직, 서비스 로직 등 다양한 이름으로 부르기도 하지만 중요한 것은 애플리케이션에서 제공하려는 기능이나 서비스를 처리해 주는 로직이라는 점에서 동일하다는 것.

 

cf) 사용자가 일반적인 애플리케이션을 이용할 때는 비즈니스 로직을 직접 접하는 것이 아니라 사용자 인터페이스(UI)를 통하는데 보통 이는 프론트엔드 기술을 이용해 개발하게 됨. html, js, react, vue 등.

 

 

SOAP(Simple Object Access Protocol)

 

 

HTTP나 HTTPS, SMTP 등을 이용해 XML 기반의 메시지를 컴퓨터 네트워크상에서 교환하는 형태의 프로토콜. 웹 서비스의 기본적인 메시지 전송 수단이기도 함. SOAP은 서비스 통신을 위해 XML-RPC라는 기술을 사용하는데 Envelope, Header, Body 구조로 전송하며 상호 중립적인 개념을 가지고 개발되어 옴. 쉽게 말해서 HTTP, HTTPS 등 통신 프로토콜을 위해서 XML 메시지를 요청하고 응답 받는 서비스. 이처럼 사용자의 메시지를 요청하고 처리하기 위해서는 메시지의 규격을 정해 놓아야 함.

 

SOAP은 proxy나 방화벽에 구애 받지 않고 비교적 쉽게 통신이 가능함. 플랫폼이나 프로그래밍 언어에 독립적이며 호가장 가능한 기술이라는 장점을 가지고 있지만 CORBA나 다른 미들웨어 기술에 비해 상대적으로 느리다는 단점이 있음.

 

2000년도 초반만 하더라도 웹 서비스 구현을 위해 SOAP 기술이 많이 고려되었으나 복잡한 구조로 인해 오버헤드가 많았음. 개발하기 어렵고 무거우며 무엇보다도 느리다는 단점으로 인해 사용하기에 문제가 있었음.

 

그래서 최근 플랫폼에서는 프로그램으로부터 독립적이고 SOAP보다 개발하기 단순한 RESTful이라는 기술이 널리 사용되고 있음.

 

REST(REpresentational State Transfer)

 

REST는 SOAP과 마찬가지로 네트워크상에서 클라이언트와 서버 사이의 통신을 하는 방식 중 하나임. REST API는 컴퓨터, 스마트폰 같은 두 단말기 간의 인터넷을 통해 정보를 안전하게 교환하기 위해 사용되는 일종의 인터페이스.

 

특히 스마트폰의 등장으로 인해 그 인기가 이어져 왔는데, 모바일 다바이스는 하나의 고정적인 하드웨어가 아니며 다양한 운영체제와 기술이 있기 때문. 이러한 이기종 단말기 간의 데이터 통신을 위해 비교적 가볍고 빠르며 호환성 있고 안전한 데이터 교환 기술을 필요로 하게 됨. REST는 이러한 특징을 모두 가지고 있는 장점이 있음.

 

REST는 상태(Status)를 전달하고 표현해 줌. 상태라는 것은 서버가 가지고 있는 리소스, 즉 자원에 대한 상태 표시. HTTP라는 Method를 이용해 리소스를 처리할 수 있도록 설계된 아키텍처. 여기서의 상태는 컴퓨터, 서버가 가지고 있는 자원을 말하는 것이고, 이러한 자원을 고유하게 표현하기 위한 이름으로써 구분지어 놓음. 헤더라는 자원의 상태, 정보를 주고받는 모든 것들을 REST라고 함.

 

REST는 기본적으로 HTTP라는 프로토콜을 사용하며 HTTP Method를 통해 각 요청 정보를 전달함. HTTP Method는 HTTP 프로토콜을 클라이언트가 서버에 전달하는 목적, 종류 등을 알려주는 수단임. 여기에는 어떤 방법으로 데이터를 요청하고 전달 받을지에 대한 정보가 포함됨. 리소스를 취득하기 위해서는 GET, 내용을 전달하기 위해서는 POST, 데이터의 업데이트를 위해 PUT, 데이터 삭제를 위해서는 DELETE.

 

그리고 모든 HTTP의 요청은 서버로부터 결과가 처리된 다음 응답 코드와 함께 처리 결과를 받게 되는데, 클라이언트가 요청한 정보가 어떤 상태로 처리되었는지 HTTP Status Codes(응답 코드)를 활용하면 바로 알 수 있게 됨(200, 404, ...).

 

REST API를 사용하면 확장성, 유연성뿐 아니라 기술에 대한 독립성이라는 특징을 가질 수 있게 됨. API 설계 시 다양한 프로그래밍 언어로 클라이언트와 서버, 애플리케이션을 개발할 수 있게 되는 것.

 

REST API는 REST 서비스를 제공하는 API(Application Programming Interface)를 뜻함. 다시 말해 REST API를 사용하는 웹 서비스를 RESTful 방식의 애플리케이션이라고 볼 수 있음.

 

RESTful 서비스를 사용하기 위해서는 HTTP 프로토콜을 사용하게 됨. 그리고 HTTP 프로토콜을 사용할 수 있는 애플리케이션을 필요로 하게 되는데 일반적으로 웹 브라우저가 많이 사용됨. 개발자는 REST 방식의 서비스 개발을 위해 직접 HTTP 프로토콜을 사용하는 애플리케이션을 사용할 수도 있고 Postman, curl과 같은 API 테스트 도구를 사용하기도 함.

 

RESTful 서비스에 의해 제공되는 모든 자원들은 각각 고유한 주소 값, 즉 URI(Uniform Resource Identifier)를 가짐. 이렇나 주소 정보와 서비스에 응답할 때는 XML, HTML, JSON과 같은 어떠한 데이터 포맷을 사용할지 결정한 후 API를 설계함.

그리고 이렇게 설계된 API의 Endpoint를 다른 쪽에서 사용할 수 있도록 공개함. Endpoint란 API를 통해 서버가 제공하는 리소스에 접근하기 위해 제공되는 주소를 말함. 사용자 목록 조회, 잔액 조회 등 작업을 하기 위해 실제로 작업해야 할 method 호출을 RESTful에서 Endpoint라고 함.

 

 

 

구글 트렌드에서의 추이를 보면 최근 HTTP 웹 서비스를 개발하기 위해 REST 방식이 더 선호됨. 그중에서도 JSON 문서 포맷을 사용하는 방법이 널리 사용되고 있음. 본 강의에서도 최근 트렌드에 맞춰 REST 방식의 웹 서비스를 개발하고 기본적인 데이터 포맷은 JSON 방식을 이용할 것임.

 

 

출처
본 포스트는 인프런 이도원 강사님의 "Spring Boot 3.x 를 이용한 RESTful Web Services 개발" 강의를 통해 직접 작성 및 정리한 글입니다.