checklist

Liste de contrôle de l'audit de l'API

Une liste de contrôle basée sur le cycle de vie permettant de vérifier l'état de préparation de l'API à travers les phases de conception, de livraison, de publication et de conformité à l'aide de critères d'audit et de preuves définis.

Résultats

  • Compréhension partagée de l’objectif et de l’utilisation de « Liste de contrôle de l'audit de l'API »
  • Approche cohérente pour appliquer « Liste de contrôle de l'audit de l'API »
  • Meilleure application des pratiques associées

Comment cela fonctionne-t-il ?

  1. Utilisez la liste de contrôle de l'audit de l'API pour vous assurer que la conception de l'API répond aux exigences fonctionnelles et non fonctionnelles, notamment en matière de sécurité, de performances et de conformité.
  2. Réalisez des audits pour évaluer la couverture du cycle de vie et vérifier que l'API respecte les normes métier, de conception et opérationnelles.
  3. S'assurer que la documentation, les modèles de sécurité, la configuration de la passerelle et les exigences légales sont clairement définis, validés et étayés par des preuves.

Contenu source

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