소프트웨어가 계속해서 세상을 먹어치우면서 실시간 정보, 원활한 통합 및 자동화에 대한 강조가 점점 더 강조되면서 웹후크가 현대 애플리케이션 아키텍처의 최전선으로 올라섰습니다. Webhooks는 이제 플랫폼 전체에서 실시간 이벤트 기반 워크플로를 구동하는 핵심 구성 요소입니다. 수 있습니다. 여기에서 전체 보고서를 읽을 웹훅 문서 검토에 협력해주신 Zoom의 Ojus Save, Intuit의 Judy Vander Sluis, Cloudinary의 Sharon Yelenik, Github의 Sarah Edwards, ReadMe의 Kanad Gupta에게 특별히 감사드립니다. 이는 사람들이 웹북 API 문서화에 대해 어떻게 생각하는지 이해하는 데 큰 도움이 되었으며 이 보고서를 작성할 때 많은 결정을 내리는 데 도움이 되었습니다. 2023년 웹훅 상태에 대한 이 종합 보고서에서 우리는 100개가 넘는 상위 API 제공업체를 살펴보고 그들이 웹훅을 수용하고 구현한 방법을 조사하고 이러한 구현이 형성되는 다양한 방식을 분석했습니다. 대부분의 선도적인 API 제공업체가 모범 사례를 갖추고 있습니까? 단순한 채택을 넘어 오늘날 개발자와 비즈니스의 요구 사항을 충족하기 위해 웹훅 제품을 어떻게 최적화하고, 보호하고, 강화했습니까? 실제 사용 사례에서 실제 정보가 자주 등장한다는 점을 인식하여 우리는 자체 고객 기반을 활용하여 웹훅 전달의 현실을 밝혀주는 흥미로운 통계 캐시를 수집했습니다. 그들은 야생에서 얼마나 자주 흔들리나요? 이러한 메시지가 원하는 애플리케이션에 성공적으로 도달하려면 일반적으로 몇 번의 재시도가 필요합니까? 이러한 직접 통계는 현재 전달 성공률에 대한 명확한 그림을 제공할 뿐만 아니라 모범 사례 구현의 가치도 보여줍니다. 일반적으로 웹훅 채택률은 83%로 높습니다. 그러나 대부분의 모범 사례 채택은 지연되고 있습니다. 재시도 재시도에는 시도가 실패할 경우 웹훅을 다시 보내는 것이 포함됩니다. 일시적인 네트워크 문제, 서버 가동 중지 시간 또는 기타 일시적인 오류로 인해 즉각적인 데이터 전달이 방해될 수 있으므로 안정적인 웹후크 서비스에 매우 중요합니다. 서비스의 67%가 자동 재시도를 제공했습니다. 제공되는 가장 일반적인 재시도 횟수는 5회이며, 대부분의 재시도 횟수는 3~10회입니다. 약 10%의 서비스는 실패한 메시지를 재시도했다고 밝혔지만 재시도 일정 자체에 대한 정보는 제공하지 않았습니다. 재시도: 지수 백오프 웹훅 재시도는 지수 백오프를 사용하여 수신 서버에 부담을 주지 않으면서 오류를 효율적으로 처리합니다. 재시도 간 대기 시간을 점진적으로 늘려 잠재적인 서버 문제를 악화시킬 위험을 줄이고 일시적인 오류 처리에 대한 보다 적응력 있는 접근 방식을 제공합니다. 결론적으로, 웹후크는 대부분의 API 제공업체에서 채택하고 있지만 대부분 모범 사례를 구현하지 못합니다. 대부분의 모범 사례를 구현하는 회사라도 다른 방식으로 구현합니다. 공간이 너무 단편화되어 유사한 구현을 갖춘 유일한 공급자는 모범 사례를 전혀 구현하지 않은 공급자였습니다. 이 보고서가 웹훅 관련 개발자 경험을 개선하는 데 도움이 되는 웹훅 모범 사례 채택의 증가를 촉발할 수 있기를 바랍니다. 수동 재시도 메시지를 수동으로 다시 시도할 수 있으면 문제 해결 속도가 빨라집니다. 다음 자동 재시도를 기다리는 것보다 즉시 재시도를 트리거하는 것이 더 빠릅니다. 12/83 공급자는 재시도를 수동으로 트리거할 수 있도록 지정했습니다. 이는 가장 적게 채택된 모범 사례였습니다. 벌채 반출 테스트, 문제 해결 및 디버깅 목적으로 웹훅 전달 시도 로그는 매우 유용합니다. 이는 채택률이 23%로 두 번째로 적게 채택된 기능이었습니다. 이벤트 유형 웹훅 소비자에게 제공되는 이벤트를 이벤트 유형으로 구성하면 사용자가 웹훅을 수신할 이벤트를 선택할 수 있으며 불필요하고 관련 없는 메시지가 전송되는 수를 줄일 수 있습니다. 93%의 제공업체가 이벤트 유형을 제공했습니다. 이는 아마도 이벤트가 웹훅의 핵심 가치라는 사실에서 비롯된 가장 널리 채택된 모범 사례입니다. 메시지 인증 사용자에게 웹훅 메시지의 원본과 내용을 인증할 수 있는 방법을 제공하는 것은 데이터가 전송 중에 변조되지 않았는지 확인하고 해당 데이터가 신뢰할 수 있는 소스에서 발생했는지 확인하는 데 필수적입니다. 83개의 웹훅 제공자 중 45개가 타임스탬프를 포함했습니다. 타임스탬프는 재생 공격을 방지하는 데 매우 중요합니다. 선적 서류 비치 웹훅 서비스를 잘 문서화하면 사용자의 시간을 절약하고 골치 아픈 일을 덜 수 있습니다. 샘플 코드가 있으면 개발자의 삶이 더 쉬워집니다. 43%만이 코드 샘플을 제공했지만 코드 샘플 포함은 HMACSHA256 서명 사용과 밀접한 상관관계가 있었습니다. 테스트 최고의 웹훅 문서는 웹훅 구현을 테스트하는 방법에 대한 지침을 제공합니다. 일반적인 지침에는 웹후크를 로컬에서 테스트하는 방법(주로 ngrok 사용), 엔드포인트를 가동하여 테스트 메시지를 수신하는 다양한 도구 나열, 테스트 이벤트 전송 기능 제공 등이 포함됩니다. 코드 샘플을 보유하는 것과 웹후크를 테스트하기 위한 지침 및 도구를 제공하는 것 사이에는 높은 상관관계가 있습니다. 배달 전체 보고서에서는 메시지 실패 빈도, 재시도 성공 빈도, 평균 응답 시간, 웹훅 메시지의 평균 페이로드 크기를 확인하기 위해 Svix의 일부 내부 데이터도 제공합니다. 전체 보고서 읽기 이와 같은 더 많은 콘텐츠를 보려면 , 또는 에서 우리를 팔로우하여 에 대한 최신 업데이트를 확인하거나 에서 토론에 참여하세요. Twitter Github RSS Svix 웹훅 서비스 커뮤니티 Slack
