게시물을 자동으로 생성할 수 있도록 앱을 Facebook에 연결하시겠습니까, 아니면 특정 해시태그가 있는 사진을 다시 게시할 수 있도록 Instagram에 연결하시겠습니까?
웹 사이트에 YouTube 동영상을 포함할 수도 있습니다. 애플리케이션 프로그래밍 인터페이스를 사용하면 이러한 모든 작업과 그 이상(API)을 수행할 수 있습니다.
Instagram API, Facebook API 및 YouTube API와 같은 API 덕분에 여러 애플리케이션이 안전하고 표준화된 방식으로 서로 "대화"할 수 있습니다.
즉, 프로그램은 다른 소프트웨어에서 기능이나 데이터를 가져오고 이를 활용하여 자체 기능이나 사용자 경험을 개선할 수 있습니다. 하지만 어떻게 앱이 다른 사람들이 이해할 수 있는 방식으로 이러한 요청을 하고, 처리하고, 응답할 수 있을까요?
이는 API가 생성된 방식에 따라 다릅니다. API(애플리케이션 프로그래밍 인터페이스) 설계를 논의할 때 가장 두드러진 API 패러다임 중 두 가지인 SOAP와 REST를 비교하는 것이 일반적입니다.
SOAP API(Simple Object Access Protocol)가 Oracle, Sun 및 PayPal과 같은 회사의 표준이 되자마자 Google, Amazon 및 eBay의 REST API에 대해 동등하고 반대되는 반응이 있었습니다.
이 게시물에서는 목적에 가장 적합한 것을 결정할 수 있도록 SOAP API와 REST API를 비교 및 대조합니다.
API 정의부터 시작하겠습니다.
API 란?
애플리케이션 프로그래밍 인터페이스는 API라고 합니다. API는 본질적으로 앱 개발을 가능하게 하는 메서드 및 기능의 모음입니다. 다양한 프로그램, 서비스 또는 운영 체제의 정보 및 기능에 액세스할 수 있습니다.
그들은 다양한 소프트웨어 시스템 사이에서 일종의 중개자 역할을 합니다. 연결되지 않은 두 프로그램 간의 "대화"를 가능하게 합니다.
거래 및 금융 시장에 적극적으로 참여하는 주식 중개인의 예를 들어 보겠습니다. 자동화 컬렉션 거래 알고리즘 API를 통해 트레이더가 선호하는 트레이딩 브로커 플랫폼에 연결할 수 있습니다. 이를 통해 거래자는 전자 거래를 실행하거나 실시간 견적 및 가격 데이터를 볼 수 있습니다.
REST 란 무엇입니까?
진정한 "웹 서비스" API에는 REST(Representational State Transfer)가 포함됩니다. REST API는 URI(Uniform Resource Identifiers, URL이 특수한 종류임), HTTP 프로토콜 및 놀라운 브라우저 호환 JSON 데이터 형식을 기반으로 합니다.
이미 언급했듯이 SOAP 프로토콜도 사용될 수 있습니다. REST API는 생성 및 확장이 쉬울 수 있지만 거대하고 어려울 수도 있습니다. 모두 생성, 확장 방법 및 수행하려는 작업에 따라 다릅니다.
리소스 제약, 감소된 보안 요구 사항, 브라우저 클라이언트 호환성, 검색 가능성, 데이터 상태 및 확장성은 실제로 웹 서비스에 적용되는 RESTful API를 개발하려는 몇 가지 이유입니다.
REST는 더 가벼운 옵션을 제공합니다. SOAP는 사용하기 어렵고 많은 개발자에게 부담이 되었습니다. 예를 들어 JavaScript와 함께 SOAP를 사용하려면 매번 필요한 XML 구조를 만들어야 하므로 간단한 작업을 완료하기 위해 많은 코드를 작성해야 합니다.
REST(일반적으로)는 XML 요청 대신 간단한 URL을 사용합니다. 더 자세한 정보를 제공해야 하는 드문 경우가 있지만 대부분의 RESTful 웹 서비스는 URL 기술만 사용합니다.
1.1개의 HTTP XNUMX 동사 GET, POST, PUT 및 DELETE는 REST에서 작업을 수행하는 데 사용할 수 있습니다. SOAP와 달리 REST는 응답이 XML에 있을 필요가 없습니다.
CSV(Command Separated Value), JSON(JavaScript Object Notation), RSS(Really Simple Syndication) 형식으로 데이터를 출력하는 REST 기반 웹 서비스를 사용할 수 있습니다(RSS).
목표는 응용 프로그램에 사용 중인 언어 내에서 구문 분석하기 쉬운 형식으로 필요한 결과를 얻을 수 있다는 것입니다.
특징
- REST는 HTTP 프로토콜로 인해 무엇보다 단순성을 강조합니다.
- 웹은 REST에 가장 적합합니다. JSON을 데이터 형식으로 사용하기 때문에 브라우저와 호환됩니다.
- REST는 뛰어난 확장성과 속도로 유명합니다.
- REST API를 통해 클라이언트-서버 연결 및 아키텍처에 더 쉽게 액세스할 수 있습니다. RESTful인 경우 데이터 페이로드를 전달하는 두 당사자 간의 왕복으로 이 클라이언트-서버 모델을 사용하여 구성됩니다.
- REST API는 단독 표준 인터페이스를 사용합니다. 모든 앱이 동일한 게이트웨이를 통해 균일하게 연결되도록 하면 애플리케이션이 API와 통신하는 방식이 간소화됩니다.
SOAP이란 무엇입니까?
SOAP(Simple Object Access Protocol)라고 하는 자체 프로토콜은 보안 및 메시지 전달과 관련된 표준을 포함하여 더 많은 표준을 지정하므로 REST보다 조금 더 복잡합니다.
이러한 고유한 규범에는 약간의 추가 오버헤드가 있습니다. 그러나 보다 광범위한 보안, 트랜잭션 및 ACID(Atomicity, Consistency, Isolation, Durability) 규정 준수 기능이 필요한 비즈니스에는 결정적인 요소가 될 수 있습니다.
이 비교를 위해 SOAP의 많은 이점이 웹 서비스 응용 프로그램에 자주 적용되지 않으므로 엔터프라이즈 유형 시나리오에 더 적합하다는 점에 유의해야 합니다.
더 높은 수준의 보안(예: 모바일 앱 은행과 상호 작용), 신뢰할 수 있는 통신이 필요한 메시징 앱, 레거시 시스템과의 상호 작용 또는 ACID 준수는 SOAP API를 사용하는 애플리케이션을 설계하려는 몇 가지 이유입니다.
SOAP에서 제공하는 메시징 기능은 전적으로 XML을 기반으로 합니다. DCOM(Distributed Component Object Model) 및 Common Object Request Broker Architecture와 같은 이전의 인터넷 비호환 기술은 Microsoft(CORBA)에서 SOAP를 처음 만들 때 SOAP로 대체되었습니다.
이진 통신에 의존하면 이러한 시스템이 실패합니다. 인터넷에서는 SOAP에서 사용하는 것과 같은 XML 메시징이 더 잘 작동합니다.
특징
- SOAP의 보안은 상당히 엄격합니다. WS-Security는 SSL 지원 외에 필요한 경우 SOAP에 추가 엔터프라이즈급 보안 기능을 제공하는 기본 제공 표준입니다.
- 신뢰할 수 있는 메시징 성능에 대한 성공/재시도 추론. REST는 표준화된 메시지 메커니즘이 없기 때문에 통신이 실패할 때만 재시도할 수 있습니다. SOAP 중간체를 사용하는 경우에도 SOAP는 내장된 성공/재시도 논리로 인해 종단 간 의존성을 제공합니다.
- SOAP는 이미 ACID 표준을 준수합니다. 트랜잭션이 데이터베이스와 상호 작용할 수 있는 방법을 지시함으로써 ACID 준수는 이상을 최소화하고 데이터베이스의 일관성을 보호합니다. ACID는 다른 데이터 일관성 모델보다 신중하기 때문에 금융 또는 기타 여부에 관계없이 민감한 트랜잭션을 관리할 때 자주 사용됩니다.
- SOAP는 전적으로 XML 기반 통신이므로 프로그래머가 이해하기 쉽습니다.
- XML 메시징 프로토콜은 HTTP 프로토콜에 추가된 것입니다.
- 한 컴퓨터에서 다른 컴퓨터로의 통신은 SOAP 메시징을 통해 전파될 수 있습니다.
- 클라이언트-서버 아키텍처도 구현할 수 있습니다. 클라이언트는 SOAP 프로토콜 메시지를 사용하여 서버 측에 있는 원격 프로시저 호출을 호출할 수 있습니다.
REST와 SOAP의 차이점
1. 구조
API는 주로 서버에 있는 애플리케이션의 비즈니스 논리의 특정 구성 요소를 표시하기 위한 것입니다. REST는 동일한 목적으로 URI를 사용하지만 SOAP는 이를 위해 서비스 인터페이스를 사용합니다.
REST API는 데이터 이후에 생성되는 반면 SOAP API는 API가 보여주는 기능 이후에 개발됩니다. 보다 기능 중심적인 SOAP와 비교할 때 REST는 보다 데이터 중심적인 디자인입니다.
2. 캐싱
캐시 가능으로 표시된 데이터는 브라우저가 서버에 새로 요청할 필요 없이 브라우저에서 다시 사용할 수 있습니다. 시간과 노력을 절약하는 것이 이점입니다.
SOAP 쿼리는 HTTP 표준에서 멱등성이 아닌 것으로 간주하는 POST 요청을 통해 제출되기 때문에 응답은 HTTP 수준에서 캐시되지 않습니다. 캐싱을 사용하려면 REST API에 이 구현이 포함되어 있지 않으므로 여전히 필요한 기술을 구축해야 합니다.
3. 리소스 및 대역폭
SOAP에서 사용하는 엔벨로프 스타일 페이로드 전송으로 인해 추가 대역폭이 필요한 오버헤드가 다소 증가합니다. REST의 가벼운 특성은 일반적으로 웹 서비스에 활용되기 때문에 이러한 상황에서 이점이 됩니다.
4. 보안
SOAP가 지원하고 전송 수준에서 SSL보다 약간 더 철저한 WS 보안이 바람직합니다. 엔터프라이즈급 보안 조치를 통합하는 것도 완벽합니다.
SSL을 사용한 종단 간 암호화는 SOAP와 REST 모두에서 지원되며 REST는 HTTP 프로토콜의 보안 변형인 HTTPS를 사용할 수 있습니다.
5. 페이로드 처리
인터넷을 통해 전송되는 데이터를 페이로드라고 합니다. "무거운" 것으로 간주되는 페이로드에는 추가 리소스가 필요합니다. XML을 활용하는 SOAP에 비해 REST는 종종 JSON과 HTTP를 사용하여 페이로드를 줄이는 데 도움을 줍니다.
생성된 코드가 포함된 특수 클라이언트 라이브러리는 매우 엄격한 통신 계약으로 인해 일반적으로 클라이언트가 SOAP API에 액세스하는 데 사용해야 합니다.
결과적으로 SOAP는 REST보다 낮은 수준의 추상화를 제공하고 서버와 더 밀접하게 연결됩니다.
REST는 언제 사용합니까?
- 공개 API 만들기: REST API는 SOAP API보다 사용 및 채택이 간단하기 때문에 공용 웹 서비스를 구축하는 데 선호됩니다. 또한 SOAP는 개방형 데이터 및 서비스로 작업할 때 이러한 특성이 필요하지 않지만 REST에는 없는 몇 가지 기본 제공 보안 조치를 제공합니다.
- 모바일 앱 구축: REST는 작고 효율적이며 상태를 저장하지 않고 캐시할 수 있기 때문에 모바일 애플리케이션 구축에 적합합니다.
- 희소한 서버 리소스 및 대역폭 활용: REST API에 대한 모든 요청은 상태 비저장이어야 합니다. 즉, 각 상호 작용은 별개이며 각 요청 및 응답에는 해당 상호 작용을 완료하는 데 필요한 모든 데이터가 포함됩니다. 서버는 각각의 요청을 새로운 요청으로 취급하기 때문에 이전 요청의 레코드를 저장하지 않습니다. 결과적으로 서버는 훨씬 적은 메모리를 필요로 하고 요청이 추가 작업이나 기록 데이터 검색을 필요로 하지 않기 때문에 더 빠르게 작동합니다.
SOAP는 언제 사용합니까?
- 특히 대기업을 위한 프라이빗 API 생성: SOAP는 분산된 분산 환경에서 데이터 흐름을 가능하게 하고 여러 온라인 보안 기능을 포함하므로 기업 응용 프로그램에 적합합니다.
- HTTP 이외의 전송 프로토콜을 기본 계층으로 사용: SOAP는 기본 계층으로 HTTP에 의존하지 않습니다. 애플리케이션에 따라 SMTP(Simple Mail Transfer Protocol), JMS(Java Messaging Service) 또는 다른 전송 프로토콜을 활용할 수 있습니다.
- 상태 저장 작업 작업: REST API에 대한 요청과 달리 SOAP API에 대한 요청은 상태 저장입니다. 즉, 서버가 클라이언트에 대한 정보를 저장하고 요청 또는 작업 체인에서 이를 활용합니다. 이것이 더 많은 서버 대역폭과 리소스를 사용하더라도 은행 송금과 같은 일상적인 또는 연결된 작업을 수행하는 데 중요합니다.
결론
REST와 SOAP API를 비교하면 REST가 SOAP보다 더 낫다는 것이 분명해집니다. 그럼에도 불구하고 SOAP API가 필요한 상황이 있습니다. 경우에 따라 웹 서비스는 REST 및 SOAP API를 결합하여 생성됩니다.
따라서 사용 사례에 따라 가장 적합한 API 스타일이 결정됩니다.
댓글을 남겨주세요.