Modern API 유형

1. Rest API(Representational State Transfer)

1. HTTP 메서드 사용:
REST는 웹 브라우징에서 이미 사용하고 있는 동일한 HTTP 메서드를 활용합니다. 이는 REST API 통신의 기본 규칙을 형성합니다

• GET: 데이터를 검색하는 데 사용됩니다 (예: "모든 사용자 보여주세요").
• POST: 새로운 것을 생성하는 데 사용됩니다 (예: "새로운 사용자 추가").
• PUT: 기존 데이터를 업데이트하는 데 사용됩니다.
• DELETE: 데이터를 제거하는 데 사용됩니다.

2. 데이터 형식:
소셜 미디어 앱을 개발할 때 특정 사용자 프로필을 표시하려면, 앱은 api.mmyapp.com/users/1와 같은 주소로 GET 요청을 서버에 보냅니다. 그러면 서버는 해당 사용자의 프로필 정보를 깔끔하고 명확한 JSON 형식으로 반환합니다

3. 상태 비저장(stateless):
서버가 이전 요청을 기억하지 않고, 각 요청이 완전히 독립적. 서버는 누가 무엇을 요청했는지 혼동하지 않고 수백만, 또는 그 이상의 사용자를 처리 가능. 여러 플랫폼에서 수 많은 사용자가 동시에 API에 접근하더라도 일관된 서비스 제공

4. 플랫폼 독립성:
동일한 REST API가 광범위하게 다른 클라이언트 애플리케이션 및 기기들과 통신할 수 있음 (eg: iPhone, Android, 웹 앱, 또는 다양한 인터넷이 되는 가전기기 모두 통신 가능)

2. SOAP API(Simple Object Access Protocol)

SOAP는 오늘날 시스템들이 서로 통신하는 방식 중 가장 오래되었고 가장 공식적인(most formal) 방법 중 하나입니다. REST가 편안한 전화 통화와 같다면, SOAP는 공식적인 비즈니스 계약에 가깝습니다

1. 공식적인 구조 및 규칙:
SOAP 메시지는 통신에 있어 엄격한 규칙을 따르도록 설계되었습니다. 이러한 공식적인 구조가 SOAP의 신뢰성을 보장합니다.

• XML 사용: 모든 SOAP 메시지는 XML로 감싸져 있으며 매우 구체적인 구조를 따라야 합니다.

• 특정 구조: 메시지는 세 가지 필수 구성 요소로 이루어져 있습니다:
  1. Envelope (봉투): 모든 것을 감싸는 역할을 합니다.
  2. Header (헤더): 메타데이터(metadata)를 포함합니다.
  3. Body (본문): 실제 요청이나 응답 내용을 담고 있습니다.
  

2. 프로토콜 독립성 (Protocol Independence):
SOAP의 핵심 강점 중 하나는 프로토콜 독립적(protocol independent)이라는 점입니다.

• SOAP는 REST처럼 가장 흔하게 HTTP 또는 HTTPS를 통해 사용되지만, SMTP, TCP 또는 기타 프로토콜 위에서도 실행될 수 있습니다.

• 이러한 전송 프로토콜에 대한 유연성은 SOAP가 다양한 엔터프라이즈 환경에서 활용될 수 있는 기반이 됩니다.

3. 내장된 표준 및 신뢰성:
SOAP는 단순히 데이터를 주고받는 것 이상의 기능을 위해 내장된 표준(built-in standards)을 가지고 있습니다. 이러한 표준은 SOAP가 높은 수준의 신뢰성과 정밀함이 요구되는 환경에서 신뢰받는 이유입니다.

SOAP가 갖춘 내장 표준

• 오류 처리 (Error handling)
• 보안 (Security)
• 트랜잭션 지원 (Transaction support)

이러한 특성 덕분에, 은행, 의료 서비스 제공자, 정부 시스템과 같은 산업들은 오늘날에도 SOAP에 크게 의존하고 있습니다. 예를 들어, 은행 간에 돈을 이체할 때 SOAP API가 뒤에서 작동하여 거래가 안전하고 정확하게 처리되도록 보장할 가능성이 높습니다.

4. API 유형으로서의 역할 및 트레이드오프:
SOAP API는 REST, gRPC, GraphQL 등 다른 현대적인 API 유형과 비교했을 때 다음과 같은 독자적인 위치를 가집니다.

• 경량성 및 유연성 대비: SOAP는 REST만큼 가볍거나 유연하지 않을 수 있습니다.

• 필요한 경우: 하지만 보장된 전달(guaranteed delivery), 엄격한 계약(strict contracts), 그리고 엔터프라이즈급 신뢰성(enterprise-grade reliability)이 필요할 때는 SOAP가 선택해야 할 API입니다

3. gRPC(Google RPC)

속도, 성능, 정밀함을 극대화하기 위해 설계된 고성능의 현대적인 RPC(원격 프로시저 호출) 방식. REST API가 제공하지 못하는 대규모 실시간 애플리케이션 요구사항을 해결하기 위해 등장

1. RPC의 배경과 gRPC의 등장:
gRPC를 이해하기에 앞서 RPC (Remote Procedure Call)의 개념을 알아야 한다.

• RPC 개념: RPC는 앱이 네트워크를 통해 원시 데이터(raw data)를 전송하는 대신, 마치 로컬에 있는 함수인 것처럼 다른 머신에 있는 함수를 직접 호출할 수 있게 하는 아이디어입니다.

• 예를 들어, 코드에서 get user 123을 작성하면, 이 요청이 네트워크를 통해 서버로 이동하여 실행되고 결과가 반환됩니다.

• 초기 RPC의 문제: XML RPC나 JSON RPC와 같은 초기 RPC 시스템은 몇 가지 문제를 가지고 있었습니다. 이들은 느리고, 텍스트 기반이며, 오늘날의 대규모 실시간 앱에는 잘 확장되지 못했습니다.

• gRPC는 이러한 초기 RPC 시스템의 문제를 해결하기 위해 등장한 Google의 고성능, 현대적 RPC 방식입니다. gRPC를 API 중의 '포뮬러 1 경주용 자동차', 속도, 성능, 정밀함을 위해 구축되었다.

2. gRPC의 핵심적인 성능 요소:
gRPC가 REST API보다 훨씬 빠른 성능을 달성할 수 있는 이유는 두 가지 핵심 기술을 활용하기 때문입니다.

A. 프로토콜 버퍼 (Protocol Buffers, Protobuf) 사용

• 데이터 형식: REST가 텍스트 기반의 JSON을 HTTP를 통해 전송하는 반면, gRPC는 프로토콜 버퍼(Protobuf)를 사용합니다.
• 이진 형식: Protobuf는 데이터를 압축된 이진 형식(compact binary format)으로 변환하며, 이는 처리 속도가 매우 빠릅니다(lightning fast). 이는 손으로 쓴 편지를 우편으로 보내는 것과 모든 파일을 압축하여 즉시 전송하는 것의 차이와 같습니다.

B. HTTP/2 활용

• gRPC는 HTTP/2를 활용합니다.
• 동시 요청 처리: HTTP/2의 장점을 이용하여 단일 연결(single connection)을 통해 여러 요청을 동시에 실행할 수 있습니다.

이러한 기술적 우위 덕분에 gRPC의 성능 이득은 엄청납니다. 많은 시나리오에서 REST보다 7배에서 10배 더 빠릅니다

3. 강력한 통신 패턴 지원 (스트리밍):
gRPC는 단순한 요청-응답 모델을 넘어, 현대의 실시간 애플리케이션에 필수적인 네 가지 강력한 통신 패턴을 지원합니다.

• 단순 요청-응답 (Simple Request Response): REST와 마찬가지로 기본적인 요청-응답 패턴입니다.
• 서버 스트리밍 (Server Streaming): 서버가 클라이언트에게 실시간 업데이트를 지속적으로 제공할 때 사용됩니다.
• 클라이언트 스트리밍 (Client Streaming): 클라이언트가 서버에 지속적인 데이터를 보낼 때 사용됩니다.
• 양방향 스트리밍 (Bidirectional Streaming): 양측(클라이언트와 서버)이 실시간으로 동시에 대화할 수 있는 방식입니다.

4. API 유형으로서의 역할 (적용 분야):
gRPC는 극도의 성능과 실시간 통신이 중요한 분야에서 '비밀 병기(secret weapon)' 역할을 합니다.

• 주요 적용 사례: 넷플릭스(Netflix), 우버(Uber), 그리고 고빈도 매매 플랫폼(high-frequency trading platforms)과 같은 시스템의 기반 기술입니다.

개발자가 gRPC를 알아야 하는 이유는, 대규모 분산 시스템을 구축하거나 극단적인 처리 속도와 효율성이 요구되는 애플리케이션을 개발할 때 gRPC가 REST API의 성능적 한계를 뛰어넘는 최적의 해결책을 제공하기 때문입니다.

4. GraphQL API(Graph Query Language)

GraphQL은 Facebook이 개발한 혁신적인 쿼리 언어이며, 우리가 데이터를 가져오는 방식을 영원히 바꿀 것입니다. 이는 특히 REST API의 근본적인 한계를 해결하기 위해 등장했습니다.

1. GraphQL이 해결하는 문제: 데이터 비효율성:
GraphQL이 다른 API 유형들과 차별화되는 가장 큰 이유는 REST API의 데이터 비효율성 문제를 정면으로 해결하기 때문입니다.

A. 오버페칭 (Overfetching)
REST API를 사용할 때 발생하는 일반적인 문제 중 하나는 너무 많은 데이터를 받는다는 것입니다.

• 예시: 사용자의 이름과 이메일만 필요한데, REST는 주소, 환경 설정, 쇼핑 기록 등 전체 프로필 정보를 보내줄 수 있습니다.
• 결과: 이러한 오버페칭(overfetching)은 대역폭을 낭비하게 만듭니다.

B. 언더페칭 (Underfetching)
또 다른 문제는 필요한 모든 것을 얻기 위해 여러 API 호출을 해야 할 수도 있다는 것입니다. 이는 언더페칭(underfetching)으로 불립니다.

• 예시: 사용자의 이름, 이메일, 상품주문 정보가 필요한데, REST는 사용자의 정보를 얻을 수 있는 API와 상품정보를 주는 API, 주문 정보를 받는 API를 호출 해야 할 수 있습니다.
• 정보를 표시해 주기위해 3개의 API를 호출해야 하는 상황. 때로는 더 많은 API를 호출해야 할 수도 있음.

2. GraphQL의 핵심 해법: 정확한 요청 (Precision):
GraphQL은 데이터 요청 모델을 완전히 뒤집어, 클라이언트가 서버에 필요한 것만 정확하게 요청할 수 있게 합니다.

• 하나의 쿼리: 개발자는 오직 하나의 쿼리만 작성하여 원하는 것을 정확하게 요청합니다.
• 선택적 데이터: 예를 들어, "사용자 이름과 이메일만 주고, 나머지는 모두 건너뛰세요"와 같이 요청할 수 있습니다.
• 결과: 이는 하나의 엔드포인트, 하나의 요청, 그리고 매번 완벽한 데이터라는 결과를 낳습니다.

3. GraphQL의 킬러 기능 및 개발자 경험:
GraphQL은 효율적인 데이터 페칭 외에도 현대 애플리케이션 개발에 필수적인 고급 기능을 제공합니다.

A. 실시간 구독 (Real-time Subscriptions)
GraphQL의 킬러 기능(killer feature) 중 하나는 실시간 구독(real-time subscriptions)입니다.

• 앱은 라이브 업데이트가 발생할 때 자동으로 수신 대기(listen for live update automatically) 할 수 있습니다. 이는 클라이언트가 서버의 특정 이벤트 발생을 즉시 알 수 있게 합니다.

B. 자체 문서화 및 플레이그라운드
GraphQL은 자체 문서화(self-documenting) 기능을 갖추고 있습니다.

• 쿼리를 즉시 테스트해 볼 수 있는 내장된 플레이그라운드(built-in playground)가 함께 제공되어 개발 편의성을 높입니다.

4. API 유형으로서의 역할 (적용 분야):
GraphQL은 성능이 중요하고, 사용자가 모바일 기기에 있으며, 프론트엔드 개발자에게 필요한 것을 정확하게 요청할 유연성을 제공하고자 할 때, REST를 대체하는 가장 좋은 API가 될 수 있습니다.

• 주요 채택 사례: GitHub의 전체 API는 GraphQL을 기반으로 구축되었으며, Shopify와 Pinterest 역시 프로덕션 환경에서 GraphQL을 사용하고 있습니다.

결론적으로, GraphQL API는 단순한 통신을 넘어 데이터 요청의 효율성과 유연성을 극대화함으로써 현대의 모바일 및 웹 애플리케이션 개발에서 필수적인 API 유형으로 자리 잡았습니다.

5. WebHook API(Reverse API)

다른 전통적인 API 유형들과는 통신 방식을 근본적으로 뒤집는 혁신적인 메커니즘을 제공합니다. 실시간 업데이트와 효율적인 데이터 동기화를 가능하게 하는 필수적인 요소로 논의됩니다. 웹훅은 리버스 API (Reverse API)라고도 불립니다.

1. 웹훅이 해결하는 문제: 폴링(Polling)의 비효율성
REST API와 같은 전통적인 API 방식에는 비효율적인 통신 방식인 폴링(polling) 문제가 내재되어 있습니다.

• 전통적인 API 방식 (폴링 비유): 소스는 대부분의 API를 사용자가 "지속적으로 우편함을 확인하는 사람"에 비유.
  • 사용자가 밖으로 나가서 우편함을 열어보고, 아무것도 없으면 돌아오기를 반복합니다.
  • 이는 앱이 새로운 일이 발생했는지 알기 위해 매번 서버에 물어봐야 하는 전통적인 API의 작동 방식입니다.
• 결과: 이러한 폴링 방식은 요청을 낭비하게 만들고 비효율적입니다.

2. 웹훅의 작동 원리: 통신 모델의 전환 (리버스 API)
웹훅은 이 모델을 완전히 뒤집어 클라이언트가 서버에 묻는 대신 서버가 클라이언트를 호출하게 만듭니다.

• 웹훅 비유: 이는 마치 "집배원이 편지가 도착하는 순간 벨을 누르는 것"과 같습니다. 즉각적이고(instant) 직접적이며(direct) 효율적입니다(efficient).
• 리버스 API: 웹훅은 앱이 데이터를 쫓아다니는 대신, 데이터가 앱을 쫓아오게 합니다. 이것이 웹훅이 리버스 API라고 불리는 이유입니다.

콜백 URL (Callback URL) 기반 통신

1. 설정: 사용자는 자신의 애플리케이션에 콜백 URL (callback URL)을 설정합니다.
2. 이벤트 발생: 새로운 결제, 코드 푸시, 양식 제출과 같은 이벤트가 서비스에서 발생할 때마다,
3. POST 요청 전송: 해당 서비스는 이벤트 세부 정보를 담은 POST 요청을 설정된 콜백 URL로 곧바로(straight) 전송합니다.

장점: 웹훅은 폴링이 없고, 요청 낭비도 없으며, 오직 실시간 업데이트(real-time updates)만 제공합니다.

3. API 유형으로서의 중요성 (실시간 웹 개발의 근간):
웹훅은 오늘날 거의 모든 현대 애플리케이션의 작동 방식을 좌우하며, 실시간 웹 개발의 보이지 않는 근간(invisible backbone)입니다.

• 자동화된 워크플로: 웹훅은 워크플로 자동화와 시스템을 즉시 동기화 상태로 유지하는 데 사용됩니다.

• 주요 적용 사례:
  - GitHub: 새 코드가 푸시될 때 웹훅을 발생시킵니다.
  - Shopify: 주문이 이루어질 때 웹훅을 트리거합니다.
  - Slack 및 Discord 봇: 명령 및 실시간 반응을 위해 웹훅에 의존합니다.
  

결론적으로, 웹훅 API는 REST, SOAP, gRPC, GraphQL이 데이터를 가져오거나 교환하는 방식(요청-응답)을 넘어서, 이벤트 기반 통신을 가능하게 하여 대규모 시스템 간의 즉각적인 동기화와 반응형 상호 작용을 보장하는 데 필수적인 API 유형입니다.

6. WebSockets API

웹소켓 API (WebSockets API)는 기존의 API 유형들이 가진 단방향 통신이나 비효율적인 폴링(polling) 방식을 극복하고, 영구적인 양방향 통신 채널을 구축하여 실시간 애플리케이션을 구현하는 데 핵심적인 역할을 하는 API 유형

1. 웹소켓의 정의 및 통신 모델:
웹소켓은 클라이언트 앱과 서버 사이에 영구적인 전화선(permanent phone line)을 개통하는 것과 같습니다.

• 양방향 통신 (Two-way communication): 일단 연결이 설정되면, 클라이언트와 서버 양쪽 모두 언제든지 즉시(anytime instantly) 서로에게 데이터를 주고받을 수 있습니다.

• 클라이언트 대기 불필요: 전통적인 HTTP 방식처럼 클라이언트가 질문을 할 때까지 서버가 기다릴 필요가 없습니다.

2. 작동 방식: 핸드셰이크(Handshake)와 영구 채널
웹소켓 연결은 독특한 시작 과정을 거치며 영구적인 채널을 구축합니다.

1. 핸드셰이크 시작: 통신은 먼저 핸드셰이크(handshake)로 시작됩니다.

2. 업그레이드 요청: 브라우저(클라이언트)는 서버에 "이것을 웹소켓 연결로 업그레이드합시다(Let's upgrade this to a websocket connection)"라는 특별한 HTTP 요청을 보냅니다.

3. 채널 개방: 서버가 이에 동의하면 "악수(shake hands)"가 이루어지고, 그 순간부터 채널은 개방된 상태로 유지됩니다.

이 과정을 통해 지속적인 양방향 통신 라인(persistent two-way communication line)이 확보되며, 이는 실시간 애플리케이션에 완벽합니다.

3. 웹소켓의 핵심 장점: 서버 푸시 (Server Push)
웹소켓의 가장 큰 강점은 서버가 클라이언트에게 데이터를 푸시할 수 있다는 점입니다.

• 서버 주도 통신: 클라이언트가 항상 통신을 시작하는 일반적인 HTTP와 달리(unlike regular HTTP where the client always initiates), 웹소켓은 서버가 무언가 발생하자마자(the moment something happens) 데이터를 클라이언트에게 밀어 넣는 것(push data to you)을 허용합니다.
• 실시간 이벤트: 이러한 서버 푸시 기능은 다음과 같은 상황에서 완벽하게 작동합니다
  • 주가 업데이트를 받는 경우
  • 채팅 메시지를 받는 경우
  • 게임 이벤트가 발생하는 순간

4. 유연성 (Flexibility):
웹소켓은 전송하는 데이터 형식에서도 유연성을 제공합니다.

• 데이터 형식: 웹소켓을 통해 다음을 전송할 수 있습니다:
  • 일반 텍스트 (plain text)
  • 구조화된 데이터를 위한 JSON
  • 이미지나 비디오 같은 이진 파일 (binary files)

5. API 유형으로서의 역할:
웹소켓 API는 앞서 논의된 다른 API 유형들과는 다른 실시간 문제를 해결합니다.

• REST, SOAP, gRPC, GraphQL과의 차이: 이들은 기본적으로 요청-응답 모델에 의존하지만, 웹소켓은 지속적인 연결을 통해 서버 주도의 데이터 전송을 가능하게 합니다.
• 웹훅과의 비교: 웹훅(Web Hook)은 서버에서 클라이언트로 일회성 POST 요청을 보내는 리버스 API 역할을 하지만, 웹소켓은 항구적인 양방향 채널을 열어두고 지속적인 스트리밍이 필요한 경우(예: 채팅, 게임)에 사용됩니다.

따라서 웹소켓 API는 즉각적인 알림이나 지속적인 데이터 흐름이 필수적인 현대 실시간 웹 환경에서 필수적으로 알아야 할 API 유형입니다.

7. WebRTC API(Web Realtime Communication)

WebRTC API (Web Realtime Communication)는 다른 API 유형들과는 달리 서버를 거치지 않는 직접적인 피어-투-피어(Peer-to-Peer, P2P) 통신을 가능하게 하는 완전한 프레임워크(full framework)입니다. 실시간 통신 및 협업 도구의 핵심 기반 기술로 논의됩니다.

1. WebRTC의 정의 및 핵심 원리
WebRTC는 단순한 단일 API가 아니라, 브라우저나 모바일 앱 간의 직접적인 피어-투-피어 통신을 가능하게 하는 완전한 프레임워크입니다.

A. 서버 없는 통신 (No Central Server)
WebRTC의 가장 큰 마법은 데이터가 중앙 서버를 통해 흐를 필요가 없다는 점입니다.

• 예시: 화상 통화나 Google Meet 통화 시, 사용자의 비디오와 오디오는 장치에서 상대방 장치로 곧바로 전송됩니다.
• 프라이버시 및 효율성: 중간에 사용자의 개인적인 대화를 저장하거나 처리하는 서버가 없습니다(no server in the middle). 이 통신은 직접적이며 실시간입니다.

B. 실시간 사용 사례
WebRTC는 다음과 같은 실시간 기능들을 구현하는 핵심 기술입니다. 이 모든 기능은 추가 소프트웨어 없이 브라우저 내에서 바로 일어납니다.

• 화상 통화 (Video calls)
• 화면 공유 (Screen sharing)
• 온라인 게임 (Online gaming)
• 즉각적인 파일 전송 (Instant file transfers)

2. WebRTC의 기술적 역할: 복잡한 네트워킹 관리
WebRTC는 복잡하고 지저분한 네트워킹 세부 사항을 내부적으로 처리하여 개발자가 쉽게 P2P 통신을 구현할 수 있도록 합니다.

• NAT 순회 (NAT Traversal): WebRTC는 장치들이 다른 네트워크를 가로질러 통신할 수 있도록 NAT 순회(NAT traversal) 문제를 해결합니다.
• 자동 협상: 최적의 오디오 및 비디오 형식을 자동으로 협상(negotiates)합니다.
• 적응형 비트 전송률 스트리밍 (Adaptive Bit Rate Streaming): 인터넷 속도에 따라 품질을 지속적으로 조정하여 부드러운 실시간 경험을 제공합니다.

3. API 유형으로서의 중요성
WebRTC는 REST, gRPC, 웹소켓 등 다른 API 유형과는 완전히 다른 통신 레이어를 다루며, 이는 현대 협업 및 미디어 앱에서 WebRTC를 필수적인 요소로 만듭니다.

• 다른 API와의 차별점:
  • REST, SOAP, GraphQL (데이터 교환): 주로 서버를 통해 구조화된 데이터를 요청하거나 교환하는 데 중점을 둡니다.
  • gRPC, 웹소켓 (고성능/지속 연결): 서버와의 빠르거나 지속적인 통신 채널을 만듭니다.
  • WebRTC (P2P 통신): 중앙 서버의 병목 현상을 완전히 제거하고(no server bottlenecks), 피어 간의 직접적인 통신을 가능하게 합니다.
• 결과: WebRTC는 서버 병목 현상을 없애고(no server bottlenecks), 더 빠른 통신과 더 부드러운 실시간 경험(smoother realtime experiences)을 제공합니다.

이러한 특성 때문에 WebRTC는 현대 화상 회의, 실시간 협업 도구 및 P2P 앱의 중추(backbone) 역할을 합니다. 개발자가 WebRTC를 알아야 하는 이유는 대규모 사용자 간의 직접적인 미디어 스트리밍 및 데이터 공유가 필요한 모든 애플리케이션의 핵심 기술이기 때문입니다.