SOAP, REST, REST API, RESTful API

h j·2023년 7월 14일

study

목록 보기

7/9

❓ SOAP

📑 개념

Simple Object Access Protocal

일반적으로 널리 알려진 HTTP, HTTPS, SMTP 등을 통해 XML 기반의 메시지를 컴퓨터 네트워크 상에서 교환하는 프로토콜이다. 서로 다른 service들간의 연동을 목적으로 상호 이해 가능한 포맷의 메세지를 송수신함으로써 원격지에 있는 서비스객체나 API를 자유롭게 사용하고자 하는 기업의 요구에서부터 탄생한 프로토콜읻다.

몇가지 형태의 메시지 패턴이 있지만, 보통의 경우 원격 프로시저 호출(Remote Procedure Call; RPC) 패턴으로, 네트워크 노드(클라이언트)에서 다른 쪽 노드(서버)로 메시지를 요청하고, 서버는 메시지를 즉시 응답하게 된다.

📑 메시지 구조

SOAP Envelop
: 모든 SOAP 메시지의 루트 요소
: Header와 Boldy 요소를 포함
SOAP Header
: Envelope의 하위 요소
: 메시지 경로를 따라 SOAP 노드로만 처리될 애플리케이션 관련 정보 전달
SOAP Body
: Envelpe의 필수 하위 요소
: 메시지의 최종 수신인을 대상으로하는 정보 포함
SOAP Fault
: Body의 하위요소이며 오류보고에 사용됨

=> ~~쉽게 생각했을 때~~
우편배달부(HTTP)가 봉투에 담긴(SOAP Envelope) 편지(SOAP Header, SOAP Body)를 배달하는 것

📑 동작 방식

UDDI 레지스트리라는 걸 통해서 웹서비스를 등록하고, 탐색하고, 바인딩해서 사용한다

WSDL은 XML, UDDI는 검색엔진~~이라고 쉽게 생각하기~~

Service requestor가 SOAP로 인코딩하여 웹서비스를 Service provider에게 요청하면
Service provider는 이걸 디코딩해서 요청한 거에 맞는 비지니스 로직을 수행하고, 그 결과를 다시 SOAP로 인코딩해서 리턴한다.

❓ REST

📑 정의 및 개념

REpresentational State Transfer

자원을 이름(자원의 표현)으로 구분해 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미한다. 즉, 자원(resource)의 표현(representation)에 의한 상태전달을 의미한다.

자원 : 해당 소프트웨어가 관리하는 모든 것 (문서, 그림, 데이터, 해당 소프트웨어 자체 등)
표현 : 그 자원을 표현하기 위한 이름 (DB의 학생 정보가 자원이면, 'students'를 자원의 표현으로 정함)
상태 전달 : 데이터가 요청되는 시점에 자원의 상태를 전달 (JSON 혹은 XML을 통해 데이터를 주고받는 것이 일반적)

REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에, 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.

어떤 자원에 대해 CRUD(Create, Read, Update, Delete) 연산을 수행하기 위해 URI(Resource)로 GET, POST 등의 방식(Method)을 사용하여 요청을 보내며, 요청을 위한 자원은 특정한 형태(Representation of Resource)로 표현된다

⁜ URI 와 URL 차이점?

URL(Uniform Resource Locator)은 인터넷 상 자원의 위치를 의미
URI(Uniform Resource Identifier)은 인터넷 상의 자원을 식별하기 위한 문자열의 구성으로, URI는 URL을 포함

📑 REST 구성요소

자원(Resource) - URI
: 모든 자원에는 고유한 ID가 존재하고, 이 자원은 Server에 존재
: 자원을 구별하는 ID는 '/exgroups/:exgroup_id'와 같은 HTTP URI
: Client는 URI를 이용해 자원을 지정하고 해당 자원의 상태(정보)에 대한 조작을 Server에 요청
행위(Verb) - Method
: HTTP 프로토콜의 Method를 사용
: GET(Read/정보 요청), POST(Create/정보 입력), PUT(Update/정보 전체 업데이트), PATCH(Update/정보 일부 업데이트), DELETE(정보 삭제, 안전성 문제로 대부분 서버에서 비활성화)의 Method를 제공
표현(Representation of Resource)
: Client와 Server가 데이터를 주고받는 형태로 JSON, XML, TEXT, RSS 등이 있다
: JSON, XML을 통해 데이터를 주고받는 것이 일반적

📑 특징

Server-Client (서버-클라이언트 구조)
: 자원이 있는 쪽이 Server, 자원을 요청하는 쪽이 Client
: REST Server는 API를 제공하고 비즈니스 로직 처리 및 저장을 책임지고, Client는 사용자 인증이나 context(세션, 로그인 정보) 등을 직접 관리하고 책임진다
: 역할을 확실히 구분시킴으로써 서로 간의 의존성을 줄인다
Stateless (무상태)
: Client의 context를 Server에 저장하지 않는다
(세션과 쿠키같은 context 정보를 신경쓰지 않아도 되므로 구현이 단순해짐)
: Server는 각각의 요청을 완전히 별개의 것으로 인식하고 처리
즉, 이전 요청이 다음 요청의 처리에 연관되어서는 안된다 (DB에 의해 바뀌는 것은 허용)
⇒ Server의 처리 방식에 일관성을 부여하기 때문에 서비스의 자유도가 높아진다
Cacheable (캐시 처리 기능)
: 웹 표준 HTTP 프로토콜을 그대로 사용하므로 웹에서 사용하는 기존의 인프라를 그대로 활용할 수 있다 (Last-Modified Tag 또는 E-Tag를 이용해 캐싱을 구현)
: 대량의 요청을 효율적으로 처리 가능
Layered System (계층구조)
: Client는 REST API Server만 호출한다
: REST Server는 다중 계층으로 구성될 수 있다
(보안, 로드 밸런싱, 암호화 등을 위한 계층을 추가하여 구조 변경 가능)
(Proxy, Gateway와 같은 네트워크 기반의 중간매체 사용 가능. 단, Client는 Server와 직접 통신하는지, 중간 서버와 통신하는 지 알 수 없다)
Uniform Interface (인터페이스 일관성)
: URI로 지정한 Resource에 대한 요청을 통일되고, 한정적으로 수행하는 아키텍처 스타일을 의미
: HTTP 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능하며, Loosely Coupoing(느슨한 결함) 형태를 갖는다 (특정 언어나 기술에 종속되지 않음)
Self-Descriptiveness (자체 표현)
: 요청 메시지만 보고도 쉽게 이해할 수 있는 자체 표현 구조로 되어 있다

❓ REST API

📑 정의와 특징

REST의 특징을 기반으로 서비스 API를 구현한 것
각 요청이 어떤 동작이나 정보를 위한 것인지를 그 요청의 모습 자체로 추론이 가능
설계시 규칙이 존재
: URI는 명사를 사용 (리소스명은 동사가 아닌 명사를 사용해야 한다)
: 슬래시(/)로 계층 관계를 표현
: URI 마지막 문자로 슬래시(/)를 포함하지 않는다
: 밑줄(_)을 사용하지 않고, 하이픈(-)을 사용
: URI는 소문자로만 구성
: HTTP 응답 상태 코드 사용 (클라이언트는 해당 요청에 대한 실패, 처리완료 또는 잘못된 요청 등에 대한 피드백을 받아야 한다)

📑 REST API와 RESTful API의 차이

REST의 설계 규칙을 잘 지켜서 설계된 API를 RESTful API라고 한다
즉, REST의 원리를 잘 따르는 시스템을 RESTful이라는 용어로 지칭된다

RESTful 하게 만든 API는 요청을 보내는 주소만으로도 어떤 것을 요청하는지 파악이 가능하다

📑 RESTful API

URI는 정보의 자원만 표현해야 하며, 자원의 행위는 HTTP Method에 명시한다는 것이 핵심

EX. https://school.com/grade : 학교의 학년들을 목록으로 받는 요청

{
"results" : [
	{"idx": 1, "name": "1학년"},
    {"idx": 2, "name": "2학년"},
    {"idx": 3, "name": "3학년"}
    ]
}

EX. https://school.com/grade/2 : 고유번호(idx)가 붙으면 id=2인 학년의 정보를 요청

{
"results" : [
    {"idx": 1, "name": "홍길동", "gender": "male"},
    {"idx": 2, "name": "성춘향", "gender": "female"},
    {"idx": 3, "name": "전우치", "gender": "male"},
    {"idx": 4, "name": "나기백", "gender": "male"},
    ...
    ]
}

EX. https://school.com/grade/2/sstudents?page=2&count=10 : 한 페이지당 10명의 데이터를 요청

{
"results" : [
    {"idx": 11, "name": "신짱구", "gender": "male"},
    {"idx": 12, "name": "김지우", "gender": "female"},
    {"idx": 13, "name": "김화석", "gender": "male"},
    {"idx": 14, "name": "박수쳐", "gender": "male"},
    ...
    ]
}

❓ SOAP와 REST 비교

📑 유사점

애플리케이션이 다른 애플리케이션의 데이터 요청을 작성, 처리 및 응답하는 방식에 대한 규칙과 표준을 설명한다
표준화된 인터넷 프로토콜인 HTTP를 사용하여 정보를 교환한다
안전하고 암호화된 통신을 위해 SSL/TLS를 지원한다
안전하고 확장가능하며 내결함성이 있는 분산 시스템을 구축할 수 있다

📑 언제 사용하는가?

SOAP와 REST 중 하나를 선택하기 전에 시나리오와 API 사용자아ㅢ 요구 사항을 고려해야 한다

1. 전체 애플리케이션 설계
모바일 앱 및 하이브리드 애플리케이션과 같은 최신 애플리케이션은 REST API에서 더 잘 작동한다. 그러나 이미 SOAP API가 있는 레거시 시스템을 통합하거나 확장해야 하는 경우 SOAP를 계속 사용하는 것이 더 나을 수 있다

2. 보안
퍼블릭 API는 보안 요구 사항이 낮고 누구나 사용할 수 있도록 하는 높은 유연성을 요구한다. 따라서 퍼블릭 API를 빌드할 때는 REST가 더 나은 선택이다. 반대로 기업 내부 요구 사항을 위한 일부 프라이빗 API는 SOAP의 WS-Security를 통해 더 엄격한 보안 조치를 취하는 것이 도움될 수 있다

3. ACID 규정 준수
SOAP에는 원자성, 일관성, 격리성, 지속성 (ACID)에 대한ㅇ 규정 준수가 내장되어 있으므로 높은 데이터 무결성 요구사항에 더 적합할 수 있다. 이 경우 REST API에는 서버 또는 데이터베이스 수준에서 상태를 적용하기 위한 추가 소프트웨어 모듈이 필요할 수 있다

📑 차이점

SOAP는 프로토콜이고 REST는 아키텍처 스타일이다. (이로 인해 동작방식이 달라짐)

1. 설계
SOAP API는 함수 또는 작업을 노출하는 반명 REST API는 데이터 기반이다.

2. 유연성
SOAP API는 엄격하며 애플리케이션 간 XML 메시징만 허용한다. 또한 애플리케이션 서버는 각 클라이언트의 상태를 유지해야 한다. 즉, 새 요청을 처리할 때 이전 요청을 모두 기억해야 한다

REST는 더 유연하며 애플리케이션에서 일반 텍스트, HTML, XML 및 JSON으로 데이터를 전송할 수 있다. 또한 무상태이므로 모든 새 요청을 이전 요청과 독립적으로 처리한다

3. 성능
SOAP 메시지는 더 크고 복잡하기 때문에 전송 및 처리 속도가 느려진다.

REST는 메시지 크기가 작기 때문에 SOAP보다 빠르고 효율적이다. REST 응답도 캐싱할 수 있으므로 서버는 자주 액세스하는 데이터를 캐시에 저장하여 페이지 로드 시간을 단축할 수 있다

4. 확장성
SOAP 프로토콜을 사용하려면 애플리케이션이 요청 간에 상태를 저장해야하므로 대역폭과 요구사항이 증가한다. 결과적으로 애플리케이션 비용이 많이 들고 확장하기 어려워진다

REST는 무상태 및 계층화된 아키텍처를 허용하므로 확장성이 뛰어나다

5. 보안
SOAP를 HTTPS와 함께 사용하려면 추가 WS-Security 계층이 필요하다.WS-Security는 추가 헤더 콘텐츠를 사용하여 지정된 서버의 지정된 프로세스만 SOAP 메시지 콘텐츠를 읽도록 한다. 이로 인해 통신 오버헤드가 추가되고 성능에 부정적 영향을 준다

REST는 추가 오버헤드 없이 HTTPS를 지원한다

6. 신뢰성
SOAP에는 오류 처리 로직이 내장되어 있으며 더 높은 안정성을 제공한다. 반면 REST는 통신 장애 발생 시 다시 시도해야 하며 안정성이 떨어진다