가장 편리하고 신뢰할 수 있는 API를 구축하는 최상의 방법을 찾는 방법은 무엇일까요? 성능, 가독성, 버전 관리, 보안, 사용성, 지원 가능성, 복잡성 등 여러 가지 요소를 고려해야 합니다. 엔지니어들은 종종 API를 어떻게 선택하고 올바르게 구축해야 하는지 결정하는 데 어려움을 겪습니다. 늘 선택의 문제입니다.

저는 각 API 설계 방법의 포괄적인 설명을 제공할 생각이 없습니다. 제 목표는 각 방법이 제공하는 가장 중요한 측면을 요약하고 적절한 비즈니스 케이스와 관련 지어보는 것입니다. 중요한 점은, 특정 부분에 대해 장점이라고 말하지 않는다면, 예를 들어 보안이나 캐싱 등, 그 부분에는 모든 것이 괜찮다는 것입니다. 이러한 것들을 혜택으로 고려하지 않습니다. 필수 요소로 간주합니다.

각 API 설계 방법을 소개, 장단점, 사용 사례의 섹션으로 나누었습니다. 소개 부분에서는 기본 정보와 자세한 내용을 찾을 수 있는 링크를 제공했습니다. 요즘 인터넷은 데이터로 가득 차 있습니다; 당신이 필요한 것은 그것을 어떻게 구조화하고 필요한 것을 찾는 지를 알면 됩니다.

API 디자인 스타일과 API 프로토콜을 혼동하지 말아주세요. 서로 다른 API 디자인 접근 방식이 내부에서는 동일한 프로토콜을 지원할 수 있습니다.

망설임이 생길 때 검토할 수 있는 장단점 목록이 있다면 올바른 결정을 내릴 수 있을 것이라고 생각합니다. 장단점의 개수만 비교하는 것이 아니라, 단순히 양적인 측면이 아닙니다. 각 항목의 주요 요소를 따져서 여러분의 요구에 적용해야 합니다. 때로는 사과와 오렌지를 비교하고 있는 것 같다고 생각하실 수 있지만, 각각의 경우에 무엇을 의미하고 있는지 명확하게 설명하려 노력했습니다.

REST

소개

클라이언트와 서버 간의 효율적인 통신 방법을 설명하는 건축 원칙의 세트입니다. REST가 반드시 HTTP/1 프로토콜만 사용해야 하거나, REST와 HTTP가 같은 것이라는 공통된 오해가 있습니다. 하지만 사실은 조금 다릅니다. 로이 필딩(Roy Fielding)은 2000년에 REST 아키텍처 스타일을 만들었습니다. 그의 박사학위 논문에는 기본 원칙이 기술돼 있습니다(제 5장 참조). 5.3.2 절에서 REST가 특정 프로토콜로 통신을 제한하지 않는다는 것을 알 수 있습니다. HTTP, 특히 HTTP/1을 사용할 때 일반적으로 REST를 사용하는 것은 강행되지 않는 표준일 뿐입니다.

REST를 사용할 때 커스텀 프로토콜을 사용할 수 있고, 동시에 HTTP 프로토콜을 사용하여 RESTful API가 아닌 API를 만들 수 있습니다. HTTP/2 또는 심지어 HTTP/3를 기반으로 한 RESTful API를 갖고 있을 수 있으므로 REST와 gRPC의 성능을 직접 비교할 수는 없습니다. 이것이 혼란스러울 수 있습니다. RESTful API라고 말할 때 HTTP/1을 기반으로 한 것을 의미하며, 그렇지 않으면 결과가 달라질 수 있습니다. REST는 다른 아키텍처 접근 방식과 마찬가지로 특정 원칙을 갖고 있습니다:

• 클라이언트/서버
• 상태를 유지하지 않음
• 캐시
• 일관된 인터페이스
• 계층 시스템
• 필요 시 코드 가져오기

이러한 원칙들은 Roy Fielding의 논문과 다른 웹사이트에서 상세히 설명되어 있습니다. 그 정보를 중복해서 제공하고 싶지는 않아요. 이러한 원칙들은 API를 설계하고 시스템에서 엔드포인트를 생성하는 방법을 안내해줍니다. 여기서도 좋은 설명을 찾을 수 있어요.

장점

1. REST 접근 방식은 매우 유연하며 복잡도에 관계없이 거의 모든 시스템에서 사용할 수 있어요. Uniform Interface 원칙에 따라 엔드포인트를 구축하면 보유한 엔티티에 대한 API를 구축할 때 문제가 발생하지 않을 뿐 아니라 시스템의 크기를 필요에 맞게 확장할 수 있어요.

2. REST API는 프로그래머가 아니더라도 쉽게 읽고 이해할 수 있어요. Swagger와 같은 도구를 사용하면 HTTP API를 쉽게 찾아볼 수 있고 모든 매개변수를 검사할 수 있어요. REST 접근 방식을 사용하면 엔드포인트가 명확하고 가독성이 좋아질 거예요.

3. 전 세계에서 매우 인기 있는 언어로, API와의 통합이 쉬워집니다. 만약 여러분이 플랫폼을 보유하고 있고 오픈 API를 제공하거나 특정 사용자와 API를 공유해야 한다면, REST 원칙에 따라 요청 구조를 설계하면 다른 개발자들이 쉽게 통합을 시작할 수 있습니다.

4. REST는 언어와 프로토콜에 중립적입니다. 이 아키텍처 스타일은 특정 언어나 프로토콜에 의존하지 않습니다. 초기 제안에서 HTTP/1을 예로 사용했지만, 이것은 필수 사항이 아닙니다. 여러분의 API를 HTTP/2 또는 HTTP/3로 이전해도 여전히 RESTful할 뿐더러 추가 혜택이 더해질 것입니다.

단점

1. 단방향 통신. REST는 클라이언트에서 서버로만 작동하며 특정 문제를 해결하기 위해 만들어졌습니다. 불행하게도 실시간 정보나 양방향 통신이 필요한 경우 다른 API 솔루션을 고려해야 할 수도 있습니다. REST는 그런 목적으로 디자인되지 않았습니다.

2. HTTP/1에 강하게 결합됨. HTTP/2 및 HTTP/3로 RESTful API를 구축할 수 있지만, 사람들은 보통 HTTP/1을 기대합니다. HTTP/1의 모든 단점을 상속받게 됩니다. 이는 특히 B2B 통합에 관련된 API인 경우 중요합니다. 클라이언트가 개발 관점에서 HTTP/2 또는 HTTP/3로 전환할 준비가 되어 있지 않을 수 있기 때문입니다.

3. 많은 API가 RESTful로 레이블링되지만 실제로 RESTful하지 않습니다. HTTP와의 강한 결합으로 인해 많은 non-RESTful API가 RESTful로 간주됩니다. 신입 개발자들에게는 이 접근 방식을 따르는 것이 매우 쉽습니다.

4. 대규모 시스템에서 지원하기 어려움. 애플리케이션이 성장함에 따라 엔드포인트 수가 매우 많아져 특정 엔드포인트 구현에서 코드 중복을 피하기가 어려워질 수 있습니다. 특히 애플리케이션의 리소스 수가 많은 경우 더욱 어려워집니다.

활용 사례

REST는 시스템 복잡성의 거의 모든 수준에 적용할 수 있습니다. 진입 장벽이 낮고 API를 거의 모든 크기에 확장할 수 있기 때문입니다. 최소한의 구성만 필요로 하며, 응용 프로그램 프로토 타입을 단 몇 일 만에 준비할 수 있습니다. REST는 전자 상거래 응용프로그램과 사무실 업무에 잘 어울립니다. 무언가를 요청하고 결과를 볼 필요가 있는 경우 REST가 이상적인 후보입니다. 모바일 폰의 주요 애플리케이션은 서버와 통신하기 위해 REST를 사용합니다. 특히 예외적으로 강력한 성능이 필요하거나 응용 프로그램이 서버와 양방향으로 강력하게 작동해야 하는 경우가 아닌 한, REST는 고려할 수 있는 최상의 옵션 중 하나입니다.

gRPC

소개

gRPC은 구글이 만든 프레임워크로, HTTP/2 프로토콜을 기반으로 합니다. 이 프레임워크는 RPC(원격 프로시저 호출) 개념을 따르며, 클라이언트가 서버에서 특정 함수를 호출할 수 있습니다. 호출은 동기적 또는 비동기적일 수 있으며, 각 함수는 proto 파일에 설명된 입력과 출력을 갖습니다. gRPC는 데이터 직렬화를 위해 Google Protobuf를 사용하여 데이터가 이진 형식으로 클라이언트와 서버 간에 전송됩니다. 이 프레임워크는 네 가지 유형의 통신을 제공합니다:

• Unary RPC
• Server streaming RPC
• Client streaming RPC
• Bidirectional streaming RPC

귀하의 요구에 따라, 통신의 잘 알려진 요청-응답 방법을 지원하거나 양방향으로 데이터를 스트리밍할 수 있습니다. 더 많은 정보를 원하시면 gRPC의 공식 사이트를 방문해보세요.

1. 속도
   gRPC는 HTTP/2 프로토콜을 사용하여 여러 요청을 병렬로 처리할 수 있습니다. 그러나 속도 이점은 gRPC를 어떤 것과 비교하느냐에 따라 달라집니다. 예를 들어, HTTP/3와 비교하면 gRPC가 느릴 수 있지만, HTTP/1과 비교하면 빠릅니다. HTTP/2는 클라이언트와 서버 사이에 지속적인 연결을 설정한 다음 이 연결을 통해 요청을 다중화하여 지연 시간을 줄이고 성능을 향상시킵니다.

2. 쌍방향 데이터 스트림
   gRPC는 쌍방향 통신을 지원하여 데이터를 양방향으로 스트리밍할 수 있습니다. 또한 클라이언트에서 호출을 통해 스트리밍을 트리거할 수도 있으며, 실시간으로 데이터 청크를 전송하는 데 유용합니다.

3. 가벼운 메시지
   Protobuf를 사용하여 gRPC는 페이로드 크기를 약 30% 감소시킵니다. 그러나 이 이점은 gRPC에만 해당되는 것은 아니며, Protobuf를 REST, HTTP/1 또는 심지어 웹소켓과 함께 사용할 수 있습니다.

4. 강력한 타입 메시지
   각 속성이 얼마나 많은 메모리를 사용하는지 구성할 수 있어 불필요한 데이터 전송을 피하고 메시지를 더 조밀하게 만들 수 있습니다.

단점

1. 가독성 문제. gRPC의 각 메소드는 요청과 응답을 위한 정의된 메시지 형식을 필요로 합니다. 이는 각기 다른 함수들이 서로 다른 메시지를 필요로 한다는 것을 의미합니다. 다수의 엔드포인트가 있을 경우, 메시지 모델이 혼란스럽고 관리하기 어려워질 수 있습니다. 메시지들이 여러 파일에 흩어져 있어 요청과 해당 함수들을 연관짓기 어렵게 만들 수 있으며, 코드가 깨끗하게 작성되지 않았다면 특히 어려울 수 있습니다.

2. 로드 밸런싱 문제. gRPC는 클라이언트 측에서만 로드 밸런싱을 수행합니다. TCP 레벨에서 지속적인 연결을 사용하고, 이 연결을 통해 추가 요청을 보내므로 표준 마이크로서비스 로드 밸런싱 도구는 도움이 되지 않습니다. 요청 수준의 로드 밸런싱을 달성하려면 클라이언트 측 로드 밸런싱을 구현해야 합니다. 이는 다양한 서버로의 지속적인 연결 풀을 관리하고 요청을 분산시키거나, 각 요청마다 새로운 지속적인 연결을 생성해야 하며, 이는 성능을 저하시킬 수 있습니다.

3. 이진 데이터. Protobuf를 사용하는 솔루션에서 이진 데이터 다루기는 흔한 문제입니다. 올바른 변환 없이는 페이로드 내용을 이해하기 어려울 수 있습니다. 이를 처리하기 위한 도구들이 있지만, 별도 설치와 구성이 필요하므로 설정 프로세스에 복잡성을 더할 수 있습니다.

4. 브라우저에서 호출이 불가능합니다. 일부 최신 브라우저는 직접 gRPC 호출을 지원하지 않아 디버깅이 복잡해지고 브라우저에서 gRPC를 직접 사용하는 것이 어렵습니다. 미래에 브라우저 지원이 개선되면 이 문제가 완화될 수 있습니다.

5. 파일 전송. gRPC는 파일 전송을 지원하지만 이를 위해 널리 사용되지는 않습니다. 1MB에서 4MB까지의 파일 크기에 대해 간단한 HTTP 파일 전송이 일반적으로 gRPC보다 우수한 성능을 보입니다. gRPC에 포함된 직렬화/역직렬화 과정의 오버헤드 때문입니다.

6. 실시간 업데이트에 너무 복잡함. gRPC는 실시간 업데이트를 지원하지만 간단한 시나리오에 대해서는 어려울 수 있습니다. gRPC 스트림을 관리하는데 들어가는 오버헤드와 복잡성이 이점을 상회할 수 있어 WebSocket 통합과 같이 간단한 솔루션을 사용하는 것이 더 실용적이고 효율적일 수 있습니다.

활용 사례

gRPC은 빠르고 효율적인 성능을 보장하는 강력하게 형식화된 통신 데이터 모델이 필요할 때 사용됩니다. 이는 마이크로서비스 아키텍처에 이상적입니다. 프로토 메시지는 저장소에서 관찰할 수 있어 서비스 간 계약을 명확히하고 엔드포인트에 외부 액세스할 필요가 없습니다. Protobuf 메시지 압축 덕분에 전송 크기가 다른 페이로드보다 30% 더 작아집니다. 또한 내부 통신의 경우 REST나 다른 API 스타일의 이점이 필요하지 않습니다. 서비스를 수평적으로 확장할 경우 gRPC 요청을 클라이언트 측에서 로드 밸런싱해야 합니다. 프론트엔드와 백엔드 사이에 gRPC를 사용하는 경우, 성능과 관련된 강력한 이유가 있어야 합니다. 예를 들어, 데이터 스트리밍과 큰 요청 페이로드를 필요로하는 경우에는 Protobuf 직렬화가 유용할 수 있습니다.

GraphQL

소개

GraphQL의 본질을 몇 문장으로 설명하는 것은 매우 어렵습니다. 간단히 말해서 GraphQL은 클라이언트 측에서 텍스트 기반의 쿼리나 뮤테이션을 작성하고 이 정보를 서버로 전송할 수 있게 해줍니다. 서버는 이 정보를 GraphQL 서버에 전달하고, 해당 스키마 정의에 따라 적절한 리졸버를 호출합니다. 쿼리는 정보를 검색하는 데 사용되고, 뮤테이션은 데이터를 변경하는 데 사용됩니다(생성, 업데이트, 삭제). 리졸버는 데이터를 어떻게 가져오고 필터링할지를 정의하는 함수입니다. 스키마는 모든 데이터 유형이 지정된 데이터 정의 모델입니다. 또한 클라이언트는 특정 데이터를 실시간으로 구독할 수 있습니다. GraphQL은 간단한 래퍼로, 특정 프로토콜에 기반하지 않습니다. 필요한 프로토콜을 자유롭게 선택할 수 있지만, HTTP가 일반적으로 인기가 많으며 구독에는 WebSockets가 사용됩니다. 자세한 정보는 GraphQL 공식 사이트를 방문해주세요.

장점

1. 프로토콜이 무관합니다. GraphQL은 특정 프로토콜에 의존하지 않으므로 HTTP/1, HTTP/2 또는 HTTP/3을 사용할 수 있습니다. 필요하다면 다른 프로토콜을 선택할 수도 있습니다. GraphQL 서버를 적절하게 구성하기만 하면 됩니다. 이를 통해 사용자 기호에 따라 구성을 결정할 수 있습니다.

2. 유연한 API 구성. GraphQL은 필터링과 중첩된 쿼리를 지원하여 클라이언트 요청에 따라 관련 데이터만 검색할 수 있습니다. 불필요한 데이터를 전송할 필요가 없어서 요청을 가볍게 만들고 성능을 향상시킬 수 있습니다. 원하는 정확한 정보를 검색하도록 요청을 쉽게 조정할 수 있습니다. 이러한 유연성은 서버에서 데이터와 로직이 부분적으로 중복된 수백 개의 엔드포인트를 생성하지 않도록 도와줍니다.

3. 실시간 업데이트. 모든 변경 사항을 구독하고 정기적으로 업데이트를 받을 수 있습니다. 이는 시스템을 보다 포괄적으로 만드는 중요한 장점입니다. 그러나 데이터 크기를 고려해야 합니다. 이러한 업데이트는 일반적으로 WebSocket을 통해 작동하며 프로토콜의 규칙을 따르고 작은 페이로드를 유지해야 합니다.

단점

1. 긴 학습 곡선. GraphQL은 복잡하며 기본 원칙을 이해하고 효율적인 API를 구축하는 데 시간이 걸립니다. 스키마를 설정하고 GraphQL 서버를 구성하고 리졸버를 정의하고 API가 정상적으로 작동하도록해야 합니다. 완전히 가능하지만 다른 맥락으로 전환하는 것이 어려울 수 있습니다.

2. 캐싱. 요청에서 정확히 필요한 것을 구성할 수는 있지만 기본 요청은 동일하게 유지되어 네트워크 수준에서 캐싱을 구현할 수 없게 됩니다. 서버 측에서 캐싱을 최적화하고, 일찍은 persistent queries와 같은 확립된 GraphQL 솔루션을 사용해야 할 수 있습니다.

3. 간단한 시스템에서의 과도한 기술 사용. GraphQL은 견고한 API를 구축하기 위해 초기 구성과 추가 리소스가 필요합니다. 단순한 시스템은 이 복잡성을 필요로하지 않을 수 있습니다. 간단한 HTTP를 사용하면 몇 시간 안에 결과를 확인할 수 있지만, GraphQL은 동일한 속도를 달성하기 위해 상당한 경험이 필요합니다.

4. 과도한 요청. GraphQL을 사용하면 불필요한 데이터의 전송을 피할 수 있지만, GraphQL이 요청하는 추가 매개변수로 인해 페이로드가 간단한 HTTP 요청보다 큰 경우가 있습니다. 차이는 일반적으로 몇 KB만 커도, 요청이 많은 경우 영향을 미칠 수 있습니다.

사용 사례

GraphQL은 리소스 수가 크게 증가할 수 있는 복잡한 시스템에 적합합니다. 초기 구성에 많은 시간을 소비하기 싫다면, 스타트업에서 사용을 추천하지 않습니다. GraphQL에 대해 아주 익숙하고 정확히 무엇을 해야 하는지 알고 있다면 다르겠지만, 그렇지 않으면 적절하게 구성하는 데 많은 시간이 소요될 것입니다. GraphQL의 매력은 서버로부터 불필요한 정보를 검색하지 않고 필요한 데이터를 쉽게 정의할 수 있는 데에 있습니다. gRPC와는 달리, 더 많거나 덜 많은 데이터가 필요한 경우 응답 메시지를 복제할 필요가 없습니다. 필요없는 정보를 제외하기 위해 중첩된 쿼리를 사용하여 데이터를 쉽게 필터링할 수 있습니다. 또한 실시간 업데이트를 간단한 엔드포인트와 결합하여 단일 API 접근 방식을 유지할 수 있습니다. 복잡한 시스템에서는 REST가 많은 엔드포인트로 인해 유지하기 어려울 수 있지만, GraphQL을 사용하면 엔드포인트를 더 우아하고 쉽게 관리할 수 있습니다.

EDA

안녕하세요!

Event Drive API를 이 목록에 포함할 지에 대해 몇 가지 의문이 있었지만, 최종적으로 중요한 부분이라고 결정했습니다. EDA를 사용하면 특정 유형의 메시지를 구독하고 시스템을 그에 맞게 구축할 수 있습니다. 이벤트의 다양한 유형과 시스템을 적절히 설계하는 다양한 방법이 있습니다. 예를 들어, 이벤트 소싱을 따르면 비즈니스 이벤트의 일련을 가지고 작업 흐름을 재현할 수 있습니다. 수백 가지의 메시지 브로커와 다양한 규모의 프레임워크가 있어 비즈니스 로직을 운영하는 데 도움이 됩니다. AMQP, MQTT 등과 같은 다양한 프로토콜이 구독자가 데이터를 얻고 이벤트가 전파되는 방법을 규정합니다. 기본적으로, EDA는 어떤 일이 일어나고 있는지 신호를 보내야 할 때 적용됩니다. 동기 이벤트보다 비동기 이벤트를 사용하는 것이 좋습니다. 동기 이벤트는 높은 혼잡도와 불필요한 종속성을 초래할 수 있습니다.

장점

1. 의존성 제거. 비동기 이벤트는 응답을 기다리지 않고 통신하는 가장 좋은 방법입니다. 이 방법에는 수많은 이점이 있습니다. 시스템의 다른 부분이 작동하지 않더라도 서비스가 계속 작동할 수 있습니다. 이벤트가 즉시 전달되는지 걱정할 필요가 없으며, 이벤트 메시지가 변경되지 않는 한 시스템의 다른 부분의 변경에 의존하지 않습니다.

2. 다양한 프로토콜 및 구현체. 다양한 프로토콜과 프레임워크가 오픈 소스로 제공되고 있습니다. 필요에 가장 잘 맞는 것을 선택할 수 있습니다. Kafka, RabbitMQ, NATS 및 심지어 Redis에도 게시/구독 구현체가 있습니다. 각 시스템에는 철저한 문서와 다양한 언어용 라이브러리가 함께 제공됩니다.

3. 확장하기 쉽습니다. 많은 메시지 브로커가 확장을 지원합니다. 클러스터 구성이 정확하다면 일반적으로 확장 문제는 발생하지 않을 것입니다. 대부분의 메시지 브로커는 수평으로 확장할 수 있으므로 리소스를 압도할 수있는 부하를 상상하기 어렵습니다.

단점

1. 메시지 유형을 확인하기 어렵습니다. 이벤트 메시지는 종종 충분히 문서화되지 않으며, 설명이 저장소 어딘가에 숨겨져 있을 수 있습니다. 서로 다른 메시지는 저장소 여러 부분에 흩어져 있어 Swagger와 같은 단일 관점이 없습니다. 그러나 개발자들이 함께 노력한다면 이를 개선할 수 있습니다.

2. 복잡한 시스템에서 혼란스러워질 수 있습니다. 처음에는 이벤트를 구성하는 것이 서비스 경계가 분리되어 독립적이기 때문에 매우 유익할 수 있습니다. 그러나 시스템이 성장함에 따라 명확한 이벤트 통신을 유지하는 것이 어려워지게 됩니다. 이벤트 구조가 강력한 프로토콜 없이 사용자 정의로 변할 수 있어서 발행자와 구독자 간의 의존성이 기하급수적으로 증가할 수 있습니다. 이로 인해 명확한 구조로 돌아가기 어려워질 수 있습니다. 데이터 플랫폼은 모든 이벤트를 집계하여 어떤 서비스든 데이터 플랫폼을 직접 쿼리할 수 있도록 해 이 문제에 대처합니다.

3. 다양한 프로토콜과 구현이 존재합니다. 이는 장담과 단점 모두 가지고 있습니다. 다양한 솔루션 범위를 가짐은 이점이지만, 이러한 솔루션에 대한 기술 스택은 다양합니다. Kafka와 RabbitMQ 간의 차이점을 이해하고, 시나리오에 맞게 어떤 것을 사용할지, 어떤 라이브러리를 통합해야 하는지, 어떻게 호스팅하고 확장해야 하는지 등을 이해하는 데 시간을 들일 수 있습니다. 개발자와 데브옵스 팀은 일부 솔루션에 대한 경험이 부족하거나 장단점을 따져봐야 할 수도 있습니다. 충분한 지식이 없으면 무언가를 놓치게 되어 설계 공백이 발생하거나 대체 솔루션을 찾아야 할 수도 있습니다.

사용 사례

거의 모든 시스템은 언젠가 이벤트 주도 아키텍처를 사용하기 시작합니다. 응답을 요구하지 않고 다른 서비스에 알리고 싶을 때, 특히 전달 보장이 100% 필요하지 않을 때는 EDA가 좋은 선택입니다. 예를 들어 전자 상거래 응용 프로그램에서 고객이 구매를 하면 서비스가 이벤트를 발생시킬 수 있고, 다른 서비스는 그에 따라 비즈니스 로직을 실행할 수 있습니다.

그러나 사람들은 때로 이벤트를 명령어와 혼동하기도 합니다, 특히 전달 보장이 필요한 경우에. 서비스에 알리고 전달이 보장되어야 하는 경우에는 HTTP 요청, gRPC 또는 다른 방법을 사용하는 것이 좋습니다. 이것은 당신의 비즈니스 로직이 다른 서비스의 응답에 강하게 의존하기 때문입니다. 예를 들어 자금 인출에 대한 이벤트를 발생시키고 잔액이 감소된 것을 모르고 구매 트랜잭션을 진행할 수 없습니다. 이러한 경우에는 동기 호출이 필요합니다.

SOAP을 언급하지 않은 이유

제 생각에 SOAP은 대부분의 옛 기업 응용 프로그램에서 주로 사용됩니다. SOAP은 XML을 기반으로 하기 때문에 무겁습니다. SOAP 아키텍처는 최근에 잘 지원되지 않으며, 적절한 라이브러리를 찾는 데 어려움이 있을 수 있습니다. 몇 년 전에는 접근 가능한 프로토콜이 부족했을 때 SOAP이 알려진 해결책 중 하나였지만, 오늘날에는 시대에 뒤떨어진 기술로 여겨집니다. 무언가를 변경하는 위험이 중대할 때만 레거시 응용 프로그램을 지원해야 하는 경우를 제외하고 SOAP을 고려해야 합니다. 본 문서는 새로운 시스템에서 사용할 방법을 결정해야 하는 사람들을 위해 작성되었으므로 SOAP을 목록에 추가하는 것은 중복될 것입니다.