한 시스템(주체)이 일부 데이터에 대해 다른 시스템(관찰자)을 계속 폴링하는 기존 시스템과 달리 웹후크를 사용하면 이벤트가 발생할 때마다 관찰자가 자동으로 데이터를 주체의 시스템으로 푸시할 수 있습니다.
이것은 주제에 의한 지속적인 모니터링의 필요성을 제거합니다. Webhook은 전적으로 인터넷에서 작동하므로 시스템 간의 모든 통신은 HTTP 메시지 형식으로 이루어져야 합니다.
웹후크는 관찰자의 시스템에서 이벤트가 발생할 때 알림을 받아야 하는 대상 시스템의 API를 가리키는 정적 URL의 존재에 의존합니다. 예를 들어 사용자의 Amazon 계정에 접수된 모든 주문을 수집하고 관리하도록 설계된 웹 앱이 있습니다. 이 시나리오에서 Amazon은 관찰자 역할을 하고 Custom Order Management Webapp는 주체 역할을 합니다.
맞춤형 웹앱이 주기적으로 Amazon API를 호출하여 생성된 주문을 확인하는 대신, 맞춤형 웹앱에서 생성된 웹후크를 사용하면 Amazon이 등록된 URL을 통해 웹앱에서 새로 생성된 주문을 자동으로 제출할 수 있습니다. 따라서 웹후크를 사용하려면 주체는 관찰자의 이벤트 알림을 수락하는 URL을 지정해야 합니다. 이는 이벤트가 발생할 때만 두 당사자 간에 HTTP 호출이 이루어지기 때문에 개체에 대한 상당한 부하를 줄입니다.
관찰자가 주체의 웹후크를 호출하면 주체는 새로 제출된 이 데이터로 적절한 조치를 취할 수 있습니다. 일반적으로 웹후크는 특정 URL에 대한 POST 요청을 통해 수행됩니다. POST 요청을 사용하면 개체에 추가 정보를 보낼 수 있습니다. 또한 각 이벤트에 대해 별도의 웹후크 URL을 생성하는 대신 가능한 다양한 이벤트를 식별하는 데 사용할 수도 있습니다.
애플리케이션에서 인바운드 웹후크를 구현하려면 다음 기본 단계를 수행해야 합니다.
웹후크와 API 모두 애플리케이션 간의 통신을 설정하는 것을 목표로 합니다. 그러나 애플리케이션 통합을 달성하기 위해 API보다 Webhooks를 사용하는 데에는 몇 가지 뚜렷한 장점과 단점이 있습니다.
다음 사항이 구현된 시스템과 더 관련이 있는 경우 웹후크가 더 나은 솔루션이 되는 경향이 있습니다.
일부 다른 상황에서는 API를 사용하는 것이 웹후크보다 선호되어야 합니다.
Webhook에서 API를 사용하기 위해 고려해야 할 중요한 사항은 다음과 같습니다.
웹후크가 오프라인이 될 때 서버에서 보낸 데이터 손실 가능성을 처리하기 위해 이벤트 메시징 대기열을 사용하여 해당 호출을 보관할 수 있습니다. 이러한 기능을 제공하는 플랫폼의 예는 다음과 같습니다. RabbitMQ o Amazon의 SQS(Simple Queue Service). 둘 다 webhook 호출을 놓칠 가능성을 방지하는 중간 메시징 저장 시설 역할을 하도록 설계되었습니다.
Ercole Palmeri
색칠을 통해 소근육 운동 능력을 키우면 아이들이 글쓰기와 같은 보다 복잡한 기술을 준비할 수 있습니다. 색칠하다…
지난 월요일, Financial Times는 OpenAI와의 계약을 발표했습니다. FT는 세계적 수준의 저널리즘에 라이선스를 부여합니다…
수백만 명의 사람들이 스트리밍 서비스 비용을 지불하고 월간 구독료를 지불합니다. 당신은…
