Integrationer
Del af Integrationer og workflows
Sammenlign webhooks og planlagte API-kald
Sammenlign webhooks og planlagte API-kald ud fra tidskrav, manglende ændringer, drift og leverandørens faktiske grænser.
Vælg en webhook, når kilden tilbyder den nødvendige hændelse, opdateringen skal ske hurtigt, og I kan drive en sikker modtager. Vælg planlagte API-kald, når et kendt opdateringsinterval er tilstrækkeligt, eller hændelsen ikke findes. Begge metoder kræver en måde at finde manglende ændringer på.
Sammenlign den samme opgave
Antag, at ændret ordrestatus skal vises i et internt system. Fastlæg først, hvor sent ændringen må være synlig, hvilke ændringer der tæller, og hvad der skal ske efter nedetid.
| Spørgsmål | Webhook | Planlagt API-kald |
|---|---|---|
| Hvad starter arbejdet? | Kilden sender en hændelse. | Modtageren spørger kilden med et aftalt interval. |
| Hvad skal I drive? | En tilgængelig modtager og efterfølgende behandling. | En tidsplan, søgevinduer og håndtering af resultatsider. |
| Hvordan findes et hul? | Afstem mod kildens poster eller brug dokumenteret genlevering. | Genoptag afbrudte kørsler og afstem de behandlede poster. |
| Hvad styrer tempoet? | Kildens levering og jeres behandling. | Interval, køretid og API'ets grænser. |
Ingen af metoderne giver i sig selv garanti for, at den tilsvarende post er opdateret i målsystemet.
Sammenligning af webhook og planlagt API-kald
- Hvad starter arbejdet?
- Kilden sender en hændelse
- Hvad skal I drive?
- En tilgængelig modtager og efterfølgende behandling
- Hvordan findes et hul?
- Afstem mod kildens poster eller brug dokumenteret genlevering
- Hvad styrer tempoet?
- Kildens levering og jeres behandling
- Hvad starter arbejdet?
- Modtageren spørger kilden med et aftalt interval
- Hvad skal I drive?
- En tidsplan, søgevinduer og håndtering af resultatsider
- Hvordan findes et hul?
- Genoptag afbrudte kørsler og afstem de behandlede poster
- Hvad styrer tempoet?
- Interval, køretid og API'ets grænser
Undersøg webhookens vilkår
En webhook kan blot fortælle, at noget er sket. Hvis beskeden mangler nødvendige felter, må modtageren hente den aktuelle post særskilt. Kontrollér hændelsestype og oprindelse med den metode, leverandøren dokumenterer. En kvittering for modtagelse skal holdes adskilt fra resultatet af den senere behandling.
GitHub er et konkret eksempel på forskellige leveringsvilkår: Modtageren skal svare med 2xx inden 10 sekunder, og GitHub foreslår en kø til senere behandling. Fejlede leveringer genleveres ikke automatisk; de kan genleveres for leveringer fra de seneste tre dage. Disse grænser gælder GitHub, ikke webhooks generelt.
Vigtige faktorer for webhooks og planlagte API-kald
- GitHub: Tid til svar på webhook (2xx)
- 10 sekunder
- GitHub: Genlevering af fejlede leveringer
- Tilbage til 3 dage
- GitHub: Grænse for REST API-forespørgsler
- Begrænset af rate limits
- GitHub: Pagination i REST API
- Støttet via sideopdeling
Gør planlagte opslag fuldstændige
Find ud af, om API'et kan søge efter både nye og ændrede poster. Et filter som »ændret siden sidste kørsel« kan give huller, hvis en kørsel afbrydes, tidsstempler håndteres forkert, eller ændringer bliver synlige sent. Gem derfor et sikkert kontrolpunkt, og flyt det først, når alle relevante sider er behandlet. Et overlappende søgevindue kan hjælpe, hvis gentagne poster håndteres sikkert.
Undersøg også, om API'et viser sletninger og hvordan det paginerer. GitHubs REST API er blot et eksempel på et API med resultatsider og grænser for forespørgsler; det valgte systems regler skal læses særskilt.
Vælg ud fra et konkret krav
Skriv den seneste acceptable opdateringstid og den ønskede kontrol ved manglende poster ned. Undersøg derefter leverandørens hændelser, søgefelter, historik, paginering, adgangsrettigheder og grænser i den relevante løsning. En webhook kan udløse arbejdet hurtigt, mens et periodisk opslag afstemmer resultatet, hvis begge funktioner findes.
