checklist

API-auditoinnin tarkistuslista

Elinkaaripohjainen tarkistuslista, jolla varmistetaan APIn valmius suunnittelun, toimituksen, julkaisun ja vaatimustenmukaisuuden osalta määriteltyjen auditointikriteerien ja todisteiden avulla.

Tulokset

  • Yhteinen ymmärrys resurssin API-auditoinnin tarkistuslista tarkoituksesta ja käytöstä
  • Johdonmukainen tapa soveltaa resurssia API-auditoinnin tarkistuslista
  • Asiaan liittyvien käytäntöjen parempi soveltaminen

Näin se toimii

  1. Varmista API-auditoinnin tarkistuslistan avulla, että API-design täyttää toiminnalliset ja muut kuin toiminnalliset vaatimukset, mukaan lukien tietoturva, suorituskyky ja vaatimustenmukaisuus.
  2. Suorita auditointeja elinkaaren kattavuuden arvioimiseksi ja varmista, että API täyttää liiketoiminta-, suunnittelu- ja toimintastandardit.
  3. Varmista, että dokumentaatio, tietoturvamallit, gateway-konfiguraatio ja lakisääteiset vaatimukset on määritelty selkeästi, validoitu ja tuettu todisteilla.

Lähdesisältö

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