Vanuit de client beoordelen
De tabel helpt bij beoordeling, zonder algemene garantie. Extra velden kunnen strikte lezers storen; nieuwe opsommingswaarden kunnen volledige gevalsafhandeling breken. Inventariseer clients, bibliotheken en aannames.
| Wijziging | Te beoordelen risico | Benodigd bewijs |
|---|---|---|
| Veld verwijderen of hernoemen | Lezen werkt niet meer | Expliciete migratie en clienttests. |
| Optioneel veld toevoegen | Strikte lezer of naamconflict | Bestaande afnemers testen. |
| Nieuwe waarde in antwoord | Onvolledige gevalsafhandeling | Gedrag bij onbekende waarden. |
| Standaardwaarde wijzigen | Andere bedrijfsuitkomst | Gevallen zonder expliciete waarde vergelijken. |
Samenbestaan organiseren
- Beschrijf oude en nieuwe structuren, standaardwaarden, fouten, paginering en rechten. Test het contract met representatieve clientgevallen.
- Kies expliciet hoe versies geselecteerd worden. Onderscheid serviceversie en OpenAPI-documentversie; controleer caches en gateways.
- Publiceer planning, migratiehulp en contact. Meet werkelijk gebruik proportioneel en plan terugkeer met behoud van gegevenscompatibiliteit.
Uitfasering en afsluiting scheiden
Deprecation meldt uitfasering; Sunset kan verwachte onbeschikbaarheid aankondigen. Headers migreren geen clients. Beoordeel resterende afnemers, verplichtingen en herstel vóór het stoppen van een versie.
Primaire bronnen
- Google AIP-180 — Backwards compatibility [EN]
- IETF RFC 9745 — Deprecation [EN]
- IETF RFC 8594 — Sunset [EN]
Impact van versie op de consument
Het toevoegen van een nummer aan een URL behoudt bestaande clients niet automatisch. Een gewijzigd type, verwachte waarde, gedrag of foutmelding kan incompatibel zijn, zelfs als het pad hetzelfde blijft.
- Inventariseer actieve clients en het waargenomen gebruik.
- Test oudere clientversies met het nieuwe contract.
- Publiceer een co-existentieperiode en inspecteer het gebruik vóór de uitfasering.
Primaire bron: IETF RFC 9457 — Problem Details for HTTP APIs. Verwante methode: lees de praktische gids.
Asynchrone API-taken
Een geaccepteerd verzoek bewijst geen afgerond werk.
- Account, operatie en herbruikbare identificatie
- Toestand, tijd, interval en verval
- Resultaat, fout, annulering en resterende gevolgen
- Eén bevoegde taak en gecontroleerde uitkomst na onderbreking
Herhaalbare acceptatiecasus
Fictief voorbeeld: deze gegevens beschrijven geen klant of waargenomen resultaat.
Casusgegevens bekijken
{
"job_id": "J-42",
"timeline": [
{
"elapsed_seconds": 0,
"http": 202,
"state": "pending"
},
{
"elapsed_seconds": 5,
"http": 200,
"state": "running"
},
{
"elapsed_seconds": 6,
"http": 200,
"state": "cancel_requested"
},
{
"elapsed_seconds": 7,
"http": 200,
"state": "succeeded"
}
]
}Verwachte beslissing
Een 200 bij het lezen van de status betekent niet dat verwerking klaar is. Na een annuleringsverzoek telt alleen de bevestigde uitkomst.
Annulering te laat aangevraagd
Fictief scenario: dezelfde taak J-42, seconden sinds indiening. De toestandsnamen horen bij dit voorbeeldcontract; HTTP schrijft ze niet voor.
| Tijdstip | Antwoord en toestand | Onderbouwde conclusie |
|---|---|---|
| +0 s | HTTP 202 · pending | Geaccepteerd voor verwerking; geen eindresultaat bevestigd. |
| +5 s | HTTP 200 · running | De status is gelezen; de taak draait nog. |
| +6 s | HTTP 200 · cancel_requested | Stopverzoek vastgelegd; annulering nog niet bevestigd. |
| +7 s | HTTP 200 · succeeded | De verwerking was sneller. Toon het bevestigde succes en controleer effecten; meld geen annulering. |
Bewijst 202 dat het werk later afkomt?
Nee. Het bevestigt acceptatie voor verwerking, niet het eindresultaat. Controleer de operatiestatus.
Primaire bron: MDN — 202 Accepted. Verwante methode: lees de praktische gids.
Softwareupdates: een gewijzigde ondertekenaar controleren
Bepaal of een ondertekend artefact bij de goedgekeurde producent, bouw en versie blijft passen.
- Leg vóór pakketcontrole de toegestane producent, sleutel of certificaatidentiteit, uitgever en bouwproces vast. Koppel verwachtingen aan de software en een al vertrouwd bevestigingskanaal. Het artefact mag niet alleen zijn eigen acceptatiebeleid bepalen.
- Vergelijk de hash van het ontvangen bestand met het onderwerp van de attestatie. Verifieer de handtekening met bedoelde vertrouwensankers, daarna identiteit, builder en parameters. Een geldige handtekening van een andere identiteit voldoet niet aan het dienstbeleid.
- Test aangekondigde rotatie, onverwachte uitgever, ontbrekende handtekening en afwijkend bestand. Houd het artefact tegen als de nieuwe identiteit onbevestigd is. Leg goedkeuring en terugweg vast; een handtekening bewijst geen afwezigheid van kwetsbaarheden.
Herhaalbare acceptatiecasus
Fictief voorbeeld: deze gegevens beschrijven geen klant of waargenomen resultaat.
Casusgegevens bekijken
{
"signature_valid": true,
"digest_matches": true,
"expected_signer": "approved-publisher",
"observed_signer": "different-publisher",
"expected": "hold_for_independent_confirmation"
}Verwachte beslissing
Fictief voorbeeld: hash en handtekening kloppen, maar de ondertekenaar is niet de goedgekeurde identiteit. Installatie wacht op onafhankelijke bevestiging van de verandering.
Primaire bron: SLSA v1.2 — Verifying artifacts. Verwante methode: lees de praktische gids.
API: uitfasering en beëindiging
De uitgebreide toelichtingen zijn in deze editie beschikbaar in het Engels.
Plan retirement beyond the version number
A published version does not say when consumers need to migrate. Connect deprecation announcements, retirement dates and existing-client tests.
- Distinguish Deprecation, Sunset and policy links.
- Check that Sunset does not precede Deprecation when both dates are provided.
- Measure remaining consumers and validate the replacement before cutover.
Compare deprecation and retirement announcements →
IETF · RFC 9745 · Deprecation · Standards Track · March 2025 · §2–5 · consulted 2026-10-23
IETF · RFC 8594 · Sunset · Informational · May 2019 · §3–5, §8 · consulted 2026-10-23