checklist

API Audit Checkliste

Eine lebenszyklusbasierte Checkliste zur Überprüfung der API-Bereitschaft in den Bereichen Design, Bereitstellung, Veröffentlichung und Compliance anhand definierter Audit-Kriterien und Nachweise.

Ergebnisse

  • Besseres Verständnis der Grundsätze der API Audit Checkliste
  • Standardisierter Ansatz mit API Audit Checkliste
  • Verbesserte Umsetzung der entsprechenden API-Praktiken

So funktioniert es

  1. Verwenden Sie die API Audit Checkliste, um sicherzustellen, dass der API-Entwurf die funktionalen und nicht-funktionalen Anforderungen erfüllt, einschließlich Sicherheit, Leistung und Compliance.
  2. Führen Sie Audits durch, um die Abdeckung des Lebenszyklus zu bewerten und sicherzustellen, dass die API den geschäftlichen, gestalterischen und betrieblichen Standards entspricht.
  3. Stellen Sie sicher, dass Dokumentation, Sicherheitsmodelle, Gateway-Konfiguration und gesetzliche Anforderungen klar definiert, validiert und durch Nachweise belegt sind.

Quellinhalt

Strategy

Strategy is Ready When...

  • API is based on clear business needs
  • All concept checklist items are audited

Architecture

Architecture is Ready When...

  • Versioning strategy decided and supported by gateway
  • Only accessible via API gateway
  • Rate limits are enforced

Design

Design is Ready When...

  • Endpoints have business value and feature descriptions
  • API hides raw backend data and is designed for shared use
  • API design is consistent with other APIs
  • Data and attribute naming uses descriptive English
  • Mandatory fields are specified
  • Dates use ISO format with timezone
  • General data uses standard values
  • Field names avoid acronyms and use full words
  • Creating new resources returns identifiers
  • Endpoint paths contain max two resources or sub-resources
  • Endpoints and attributes include examples
  • POST is used for create or update
  • DELETE is used to remove resources
  • GET has no request body and returns content
  • GET returns 204 if response body is empty
  • POST returns 200 OK when updating
  • POST returns 201 Created with ID on create
  • DELETE returns 204 on success
  • 400 errors provide specific error information
  • 401 Unauthorized for wrong credentials
  • 403 Forbidden for unauthorized operations
  • Spec contains request and response schema
  • UUIDs or pseudo-identifiers instead of DB IDs
  • No sensitive data in URLs
  • HTTP methods only for intended resources

Delivery

Delivery is Ready When...

  • All prototype and design items are audited
  • Spec validated on every change
  • Schema and examples pass validation
  • Uses HTTPS or encrypted protocols
  • Endpoints protected by authentication
  • Token-based authentication
  • Protected against CSRF
  • Inputs auto-validated by framework
  • Outputs auto-escaped by framework
  • Encryption for data in transit and storage
  • Message integrity implemented

Publishing

Publishing is Ready When...

  • Published via API management
  • Visible in developer portal
  • Docs auto-generated from spec and schema
  • Spec auto-updated to gateway and dev portal
  • Published under official organization domain

Improving

Improving is Ready When...

    Related stations