Verbonden diensten

Ontwerp betrouwbare API’s en koppelingen met duidelijke afspraken, toegangsregels en foutafhandeling.

52 artikelen · Laatst bijgewerkt artikel

De zoekopdracht doorzoekt alle artikelen over dit onderwerp, inclusief het archief en de artikeltekst.

Begrijp het onderwerp

Een praktische handleiding voor dit onderwerp

Een verbonden functie is afhankelijk van identiteiten, interfacecontracten, leveranciers en faalmodi. Deze categorie verbindt API-ontwerp, beveiliging, continuïteit en de kwaliteit van de service die gebruikers ontvangen.

Wat te onderzoeken
  • Identificeer de aanroepen die essentieel zijn voor elk traject en hun eigenaren.
  • Plan deadlines, fouten, veilige herhaalpogingen en zichtbare degradatie.
  • Oefen storingen, herstel en incidentafhandeling.
  • Vergelijk de werkelijke reacties met het gedocumenteerde contract voordat een interface wordt gewijzigd.
  • Test rechten op elk GraphQL-object en -veld en koppel vervolgens nesting, lijsten en aliassen op basis van de werkelijke kosten.
  • Zet een ontvangen melding om in een uniek, traceerbaar bedrijfseffect dat na een storing kan worden hersteld.
  • Scheid gedeelde, privé- en applicatiecaches, inspecteer sleutels, hervalidatie en ongeldigverklaring na wijzigingen in toegangsrechten.
  • URL-import kan onbedoeld interne bronnen bereikbaar maken.
  • Limieten beïnvloeden capaciteit, herhalingen en verdeling tussen klanten.
  • Wijzigende data kunnen ontbrekende of dubbele records veroorzaken.
  • Ontvangen bestanden worden voor publicatie of verwerking gecontroleerd.
  • Een gedeelde cache scheidt openbare inhoud van persoonlijke antwoorden.
  • Een geaccepteerd verzoek bewijst geen afgerond werk.
  • Scheid geproduceerde, ontvangen en bruikbare events; stilte bewijst geen afwezigheid van incidenten.
  • Leg een berichtcontract voor iframe of popup vast dat onverwachte afzenders en gegevens afwijst.
  • Controleer paden, links en uitgepakte gegevens voordat bestanden worden vrijgegeven.
  • Volg vernieuwing tot de eindpunten en clients voordat de wijziging wordt afgerond.
Nuttige vragen
  • Wat gebeurt er als een provider niet meer reageert?
  • Kan een herhaalpoging een actie herhalen?
  • Welk bewijs toont aan dat herstel werkt?
  • Welke bestaande clients zouden door een nieuwe versie worden beïnvloed?
  • Kan een resolver een privéveld retourneren nadat de parent toestemming heeft gekregen?
  • Welke bytes zijn ondertekend?
  • Betekent geen cache dat er niets wordt bewaard?
  • Is alleen de eerste URL controleren voldoende?
  • Bewijst 429 dat een eerdere schrijfactie niet is uitgevoerd?
  • Bewijst het verwachte aantal rijen dat de export compleet is?
  • Bewijst een toegestane extensie veiligheid?
  • Voorkomt een cookie gedeelde caching?
  • Bewijst 202 dat het werk later afkomt?
  • Bewijzen drie ontvangen rijen drie bewaarde events?
  • Is event.origin controleren voldoende?
  • Garandeert een klein archief of filter veiligheid?
  • Is geslaagde ACME-vernieuwing voldoende?

Illustratief beslissingsvoorbeeld

Situatie
Fictief voorbeeld: deze gegevens beschrijven geen klant of waargenomen resultaat. Twee leesacties zijn snel, maar één toont na een bronwijziging nog de oude beschikbaarheid.
Controleren
Vergelijk waarde, versie, leeslocatie en tijd sinds wijziging. Test ongeldig maken, verlopen en toegang tot de bron volgens de systeemafspraken.
Handelen
Bepaal aanvaardbare veroudering per toepassing en bewaak verschillen. Lagere vertraging bewijst geen consistentie van geleverde gegevens.

API-cache: actualiteit, isolatie en consistentie beheersen

HTTP-caching: bescherm gepersonaliseerde antwoorden

IETF — RFC 9111, HTTP Caching

Controleer ontvanger en machtigingen

Een ondertekend token autoriseert niet automatisch een objectbewerking. Test de uitgever, doelgroep, vervaldatum en toegang tussen accounts; voeg verwachte weigeringen toe naast succesvolle gevallen.

Wordt een token dat geldig is voor een andere API of rol daadwerkelijk geweigerd?

De methoden verkennen

Gegevens lezen en beslissen

API-herhalingen: het hele tijdbudget tellen

Vier pogingen bevatten drie herhalingen.

Pogingen totaal
41 + 3
Wachttijden samen (ms)
700100 + 200 + 400
Modelbudget (ms)
17004 × 250 + 700

Fictief leervoorbeeld: de cijfers beschrijven CIE noch klanten.

Een herhalingsbudget proberen

n × T + W × (2^(n−1) − 1)

Vragen ter voorbereiding van uw beslissingen

Vind antwoorden en praktische controles in de analyses binnen dit onderwerp.

Verder lezen in het archief

Meer analyses over dit onderwerp, naast de recente artikelen hieronder.

Referenties: gegevens, gebruik en grenzen

Documentatie geraadpleegd op .

De uitgebreide toelichtingen zijn in deze editie beschikbaar in het Engels.

Threat intelligence: content, exchange and sharingThree distinct functions. STIX 2.1 · Describe. TAXII 2.1 · Exchange. TLP 2.0 · Share. None establishes truth alone. Objects and relationships. Collections and protocol. Permitted recipients. Local validation: origin, period, relevance and permissions.Threat intelligence: content, exchange and sharingThree distinct functionsNone establishes truth aloneSTIX 2.1 · DescribeObjects and relationshipsTAXII 2.1 · ExchangeCollections and protocolTLP 2.0 · SharePermitted recipientsLocal validation: origin, period, relevance and permissions
Threat intelligence: content, exchange and sharing
Referenties: gegevens, gebruik en grenzen
Bron en doelGecontroleerde gegevens of maatstafPraktisch gebruikTe behouden beperking
MITRE · Common Weakness Enumeration

Name classes of software and hardware weakness.

 A CWE describes a weakness that can contribute to vulnerabilities. It does not represent a particular incident. Connect the weakness to the observed mechanism: input, processing and missing control. Use it to fix the cause and plan regression tests.

Verdiep de methode →

 A keyword in a report alone does not establish the correct CWE classification.
OASIS · STIX 2.1

Describe threat intelligence through structured objects and relationships.

 STIX 2.1 is an OASIS Standard dated 10 June 2021. It defines objects, properties and JSON serialisation. Keep identifiers, dates, provenance and relationships. Check that the recipient interprets the same object type and validity period.

Verdiep de methode →

 A syntactically valid object can still be stale, misattributed or weakly supported.
OASIS · TAXII 2.1

Exchange threat intelligence through an application protocol.

 TAXII 2.1 is an OASIS Standard dated 10 June 2021. It includes service discovery and access to collections. Test authentication, collection permissions, pagination and recovery after interruption. Record which objects were actually received and processed.

Verdiep de methode →

 TAXII transports data; it replaces neither the content model nor assessment of reliability.

Identiteit: factoren, sessies en herstel

De uitgebreide toelichtingen zijn in deze editie beschikbaar in het Engels.

Identity APIs: separate authentication and authorisation

A valid token identifies a session or identity under its protocol. It does not automatically grant access to every business object. Recovery and revocation must be checked on the consuming backend.

  • Check applicable issuer, audience, expiry and permissions.
  • Replay access to an unauthorised object and a revoked session.
  • Record useful decisions without logging authentication secrets.

Open the authenticator and recovery comparison →

Sources consulted on · NIST SP 800-63B-4 · final publication NIST · Authenticator Event Management W3C · WebAuthn Level 3

ETag, HTTP-cache en gelijktijdige wijzigingen

De uitgebreide toelichtingen zijn in deze editie beschikbaar in het Engels.

Specify conflicts in the API contract

The contract should explain which validator accompanies a representation and how clients handle refusals.

  • State whether PUT requires a conditional field and when 428 is issued.
  • Document strong If-Match, 412 and the conflict-resolution journey.
  • Support HEAD and 304 without content and test SDK behaviour.

Explore ETag comparisons and the simulator →

References reviewed · RFC 9110 · §13 · RFC 9111 · RFC 6585 · §3

Retry-After: wachten, budget en herhalen

De uitgebreide toelichtingen zijn in deze editie beschikbaar in het Engels.

Specify permission to repeat before retry timing

Retry-After describes waiting. The contract must also define replayable operations, keys, versions and unknown-result states.

  • State whether the field is seconds or a date and how clients handle absent or invalid values.
  • Name the retry controller and global budget to prevent overlapping attempts.
  • Retain parameters, context and the idempotency window without generalising Stripe to every API.

Explore Retry-After and the retry model →

References reviewed · RFC 9110 · §9.2.2, §10.2.3 · RFC 6585 · §4 · AWS

De CISA KEV-catalogus verkennen

De uitgebreide toelichtingen zijn in deze editie beschikbaar in het Engels.

One identifier can span several technical layers

An entry may concern a library, server or component embedded in an appliance. Search the exact name, known dependencies and the distributed product’s advisory. Catalogue aliases are not a complete list of affected versions.

  • Connect the CVE, component supplier and final-product supplier.
  • Check version, configuration and execution path in the authorised environment.
  • Do not infer remediation from an empty search result.

Catalogus en methode bekijken →

CISA KEV · 2026.10.21 · Documentary review : 2026-10-22

Extensies: rechten en toegang

De uitgebreide toelichtingen zijn in deze editie beschikbaar in het Engels.

Robust authentication does not describe extension access

Phishing resistance does not remove the need to examine what runs in the browser after a session opens. A manifest provides clues about cookies, scripting, debugging and identity without establishing collection.

  • Test approved extensions in a profile dedicated to sensitive operations.
  • For identity, inspect OAuth scopes and recipients; this permission does not enumerate identity-provider rights.
  • Distinguish session revocation, token revocation, extension disablement and native-component removal.

Read the permission directory and manifest examples →

Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent

Syslog-codes en verzamelbewijs

De uitgebreide toelichtingen zijn in deze editie beschikbaar in het Engels.

Normalisation must preserve event meaning

In a distributed API, a PRI integer combines two codes. An opaque conversion may lose the message family or reverse severity. Test collection with identified events before inferring operational reliability.

  • Keep facility, severity and raw value in separate fields.
  • Distinguish source time, reception time and search availability.
  • Expose rejected events, truncation, loss and conversion rules.

Read syslog codes and try the PRI calculation →

IANA · syslog Parameters · Registry updated 2016-04-26 · consulted 2026-10-23

ASD ACSC and partners · Best practices for event logging and threat detection · Published and reviewed 2024-08-22 · consulted 2026-10-23

API-fouten: typen, statussen en bewijs

De uitgebreide toelichtingen zijn in deze editie beschikbaar in het Engels.

Include errors in contract tests

A new type URI, removed extension or changed status may alter consumer behaviour. Failure examples are part of the contract alongside successful responses.

  • Replay existing clients against representative refusals.
  • Check tolerance of unknown extensions and localised text.
  • Document migration of a problem identity and actually observed use.

Explore problem types and eight fictional responses →

IETF · M. Nottingham, E. Wilde, S. Dalal · RFC 9457 · July 2023 · obsoletes RFC 7807 · §3.1, §3.2, §4.2, §5

GraphQL: fouten, lijsten en gedeeltelijke data

De uitgebreide toelichtingen zijn in deze editie beschikbaar in het Engels.

GraphQL API: contract, access and reading experience

Extend API checks with partial-response acceptance cases, field-access tests and a resource budget specific to the service.

  • Compare absent data, partial data and data: null.
  • Keep the original path even when a parent becomes null.
  • Test permissions, quotas and interface states separately.

Explore GraphQL responses and nullability →

GraphQL Specification · September 2025 · Published edition · September 2025

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

Bronnen en richtlijnen

Oorspronkelijke documenten van de organisaties achter deze methoden en standaarden.