Post

API 아키텍쳐의 6가지 대표 스타일 (RESTWebhookWebSocketGraphQL 등)

Posted
By papooo
12 min read
✏️ Edit
API 아키텍쳐의 6가지 대표 스타일 (RESTWebhookWebSocketGraphQL 등)

SOAP, GraphQL, WebHook 등 용어만 들어보고 어떤 것인지 정확히 잘 몰랐었는데요, 미디엄의 간략한 글을 통해 공부해보았습니다.

특히 Webhook의 사용 사례와 REST 방식의 무상태성에 대한 설명에 대해 추가하였습니다!

6 Popular API Architecture Styles

Image

gRPCA

  • “Google Remote Procedure Call” 의 약자
  • 언어에 구애받지 않아, 다양한 언어로 구현된 마이크로서비스 설계 프로그래밍에 적합
  • 프로토콜 버퍼(protobufs)를 사용하여 메시지 크기가 작고, 통신 속도가 빠르다. (=> 효율적 데이터 직렬화)
  • 마이크로서비스 구축에 자주 사용되어, client-server / server-server 통신에 모두 사용 가능하다.

SOAP

  • “Simple Object Access Protocol”의 약자
  • XML 기반의 메시지 형식을 가지며, 고도로 구조화되고, self-describing이 가능하다.
  • 엄격한 표준과 메시지 형식이 정해져 있어서, 다른 웹 서비스 프로토콜에 비해 유연성이 떨어진다.
  • HTTP, SMTP 등 다양한 통신 프로토콜을 지원한다.
  • 안정성, 보안 기능, 복잡한 트랜잭션 지원에 적합하다.

GraphQL

  • GraphQL은 API를 위한 쿼리 언어이자 런타임으로, 클라이언트가 필요한 데이터를 정확하게 요청할 수 있도록 해준다. (클라이언트가 너무 많은 데이터를 가져오거나, 필요한 데이터를 충분히 못가져오는 문제를 줄여준다.)
  • REST API는 각 요청에 대해 고정된 엔드포인트를 사용하지만, GraphQL은 모든 쿼리와 변경 작업을 하나의 엔드포인트로처리한다. (하나의 엔드포인트로 다양한 데이터를 자유롭게 요청할 수 있다.)
  • REST API는 클라이언트가 이미 정해진 엔드포인트에서 미리 정의된 데이터만 가져올 수 있는데, 이와 달리 GraphQL은 클라이언트가 원하는 필드를 직접 지정해 요청할 수 있다.
  • introspection 기능이 있어, 클라이언트가 GraphQL 스키마에 어떤 타입과 작업이 있는지 확인할 수 있다. 즉, 어떤 데이터를 요청할 수 있는지 미리 스키마를 통해 알 수 있어 유연하게 사용할 수 있다.
  • 모바일 앱처럼 데이터 요구 사항이 동적인 애플리케이션에 적합하다. (REST보다 유연하고 효율적인 API 구축이 가능하다.)

Webhook

  • 어플리케이션과 시스템 간의 실시간으로 데이터를 주고받기 위한 메커니즘이다.
  • 한 어플리케이션이 다른 어플리케이션에서 제공한 미리 정의된 URL로 HTTP POST 요청을 통해 특정 이벤트가 발생했을 때, 이를 알리거나 트리거를 거는 방식으로 작동한다.
  • 예를 들어, 특정 이벤트가 발생하면(예: 사용자 결제 완료) 즉시 다른 어플리케이션으로 해당 이벤트에 대한 정보를 웹훅으로 전달한다.
  • 보통 이벤트 중심의 아키텍쳐에서 사용되고, 알림을 보내거나 업데이트를 전달하거나 자동화된 프로세스를 실행하는데 유용하다.

[ 사용 사례 ]

결제 시스템 알림 (Stripe, PayPal 등)

  • 결제 플랫폼에서 사용자가 결제를 완료하면, 결제 완료 정보를 웹훅을 통해 다른 애플리케이션(예: 쇼핑몰 백엔드 서버)으로 전달한다. 이를 통해 결제 상태 업데이트나 주문 처리 자동화가 가능하다.
    • 쇼핑몰 서버 → PayPal: 쇼핑몰 서버는 고객이 결제를 요청하면 PayPal에 결제 요청을 보냄.
    • PayPal → 쇼핑몰 서버 (웹훅): 결제가 완료되면, PayPal은 웹훅을 통해 쇼핑몰 서버에 결제가 완료되었음을 알림.

깃(Git) 푸시 알림

  • 개발자가 Git 저장소에 코드를 푸시(push)할 때, 웹훅을 설정하면 저장소에 새 코드가 추가되었음을 CI/CD 도구(예: Jenkins, gitlab Pipeline)에게 알려준다. 이렇게 하면 코드를 자동으로 빌드하고 테스트할 수 있다.

채팅봇 알림

  • 슬랙(Slack)이나 디스코드(Discord) 같은 채팅 애플리케이션에서 특정 이벤트가 발생했을 때 웹훅을 통해 자동으로 알림 메시지를 보낸다. 예를 들어, 서버 상태 모니터링 도구가 서버에 문제가 발생하면 해당 정보를 실시간으로 슬랙 채널로 알리는 것이다.

CRM 시스템 연동

  • 고객 관계 관리(CRM) 시스템에서 새로운 고객이나 리드가 추가되면 웹훅을 통해 이를 마케팅 도구나 이메일 마케팅 시스템에 실시간으로 전송하여 자동으로 캠페인을 시작하거나 고객 정보를 업데이트할 수 있다.

이메일 마케팅

  • 이메일 마케팅 플랫폼에서 구독자의 상태가 변했을 때(예: 구독 취소) 웹훅을 사용해 CRM 시스템이나 다른 애플리케이션으로 즉시 알린다. 이를 통해 마케팅 전략을 실시간으로 조정할 수 있다.

REST

  • 서버와 클라이언트가 HTTP를 통해 데이터를 통신할 수 있도록 해준다.
  • REST API는 리소스(데이터)를 URL로 표현하고, 이를 조작하기 위해 표준 HTTP 메서드를 사용한다.
  • REST 는 Stateless(무상태성)을 지향한다. 즉, 서버는 각 클라이언트의 상태를 저장하지 않고 (세션 정보, 요청 간의 연결 상태 등) , 클라이언트의 각 요청에 필요한 모든 정보를 포함하고 있어야 한다.
  • 서버는 각 요청을 독립적으로 처리하여 이전 요청의 상태를 저장하거나 유지하지 않음
  • 클라이언트는 서버에 요청을 보낼 때, 서버가 요청을 처리하는 데 필요한 모든 정보를 요청에 포함시켜야 한다. <- 서버는 클라이언트의 상태를 저장하지 않기 때문에 각 요청은 그 자체로 완전한 정보여야 한다.

    예를 들어:

    • 클라이언트가 첫 번째 요청으로 서버에 로그인을 했다면, 서버는 이 요청을 처리하고 응답할 때 토큰을 발급할 수 있습니다.
    • 두 번째 요청에서 클라이언트가 데이터를 요청할 때, 클라이언트는 이전에 받은 토큰을 포함해서 서버로 요청을 보내야 합니다. 서버는 이전 요청의 상태를 기억하지 않기 때문에, 클라이언트가 다시 보내는 이 토큰을 기반으로 인증을 확인합니다.

WebSocket

  • 클라이언트와 서버 간의 양방향 실시간 통신을 가능하게 하는 프로토콜이다.
  • 한 번 연결이 성립되면, 수명이 긴 단일 연결을 유지하면서 양쪽에서 데이터를 실시간으로 주고받을 수 있다.
  • 양방향 통신으로, 서버는 클라이언트의 요청이 없이도 데이터를 보낼 수 있으며, 클라이언트도 마찬가지이다.
  • 실시간 데이터 전송을 필요로 하는 어플리케이션에 적합하다. (채팅, 게임, 금융거래 플랫폼 등)
  • HTTP는 요청마다 새로 연결을 맺고 응답을 받은 후 연결을 끊지만, WebSocket은 단일 연결을 유지하여 이를 유지한다.

    HTTP는 실시간 데이터를 주고 받으려면 주기적으로 완료가 되었는지 클라이언트에서 서버에 요청을 보내는 방식(poliing)을 사용해야 해서 오버헤드와 지연을 초래할 수 있다.

  • 지속적으로 데이터를 주고받을 수 있어 지연시간이 줄어들고, 네트워크 자원을 절약할 수 있다.
  • HTTP에 비해 구현이 복잡하고, 서버 측에서 많은 동시 연결을 처리해야 해서 복잡한 리소스 관리가 필요하다. 또한 지속적인 연결 유지를 위해 메모리와 네트워크 리소스 소모가 크다. 보안 관리가 까다롭다.
Architecture
API Architecture