# API-Design — API-Produktisierungszyklus

Canonical page: https://apiopscycles.com/de/cycles/api-productization-cycle/stations/api-design

Language: de

Entity ID: api-design

Cycle: [API-Produktisierungszyklus](https://apiopscycles.com/de/cycles/api-productization-cycle.md)

Read [shared station guidance](https://apiopscycles.com/de/stations/api-design.md) first. The sections below supplement or replace the corresponding shared sections for this cycle. Sections not repeated here retain the shared guidance.

## Journey entry criteria

- Die Capability erfüllt einen klaren Geschäftsbedarf und kann von den vorgesehenen Nutzern wiederverwendet werden. — The API meets a clear business need and is reusable for multiple API consumers. (ID: api-reusability)
- Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion. — The API is intended to shield consumers from backend complexity and inconsistencies. (ID: hide-backend-discrepancies)
- Das Wertversprechen der Capability wurde mit Geschäfts- und Nutzer-Stakeholdern validiert. — The API value proposition has been reviewed and validated with the relevant business and consumer stakeholders. (ID: value-prop-validated)
- Die Nutzersegmente sind identifiziert. — API consumer segments (internal and external) are identified. (ID: consumer-segments-identified)
- Eine übergeordnete Roadmap für die Umsetzung ist definiert. — High-level roadmaps for API development are established. (ID: api-roadmap-defined)

## Journey exit criteria

- Die gewählte Architektur, Plattform und der Implementierungsstil wurden mit den relevanten Architektur-, Sicherheits- und Plattform-Stakeholdern validiert. — The chosen API architecture and platform patterns have been validated with the relevant architecture, security, and platform stakeholders. (ID: architecture-patterns-validated)
- Die gewählte Schnittstelle bietet Nutzern eine angemessene Abstraktion. — The API is intended to shield consumers from backend complexity and inconsistencies. (ID: hide-backend-discrepancies)
- Das Schnittstellendesign und die offengelegten Capabilities lassen sich klar auf Geschäftswert und Nutzerbedürfnisse zurückführen. — The API design and exposed capabilities clearly trace back to business value and user needs. (ID: design-reflects-business-value)
- Das Schnittstellendesign folgt den vereinbarten Designstandards und Konventionen. — The API design follows our shared API product and design conventions. (ID: api-consistency)

## Description

Erstellen Sie API-Designs, die konsistent, wiederverwendbar und auf Geschäftszielen und gemeinsamen Standards basieren.

## Why it matters

Beim Entwurf von APIs geht es nicht nur um die Benennung von Endpunkten. Gutes Design stellt sicher, dass APIs benutzerfreundlich, konsistent und auf Geschäfts- und technische Ziele ausgerichtet sind. Schlecht gestaltete APIs führen zu enger Kopplung, geringer Wiederverwendung und kostspieligen Nacharbeiten in den Teams.

## Apply in work

Bereitstellung von wiederverwendbaren Designmustern, gemeinsamen Standards und Validierungstools für API-Spezifikationen. Sicherstellen, dass Designentscheidungen konsistent, frühzeitig überprüft und auf die Geschäftsabsicht ausgerichtet sind.

## Outcomes

- Gut dokumentierte und konsistente API-Designs
- Wiederverwendbare und validierte API-Schnittstellenverträge
- Entwürfe, die auf Domänenmodelle und Interaktionsmuster abgestimmt sind
- Rückverfolgbarkeit des Designs zum Geschäftswert

## Steps

1. Definieren Sie zentrale Entitäten, ihre Attribute und Beziehungen, um ein gemeinsames konzeptionelles Verständnis für alle APIs zu schaffen.
2. Verwenden Sie das Interaction Canvas, um zu definieren, wie die Nutzer mit der API interagieren werden, um sicherzustellen, dass sie ihren Bedürfnissen und Erwartungen entspricht.
3. Wenden Sie REST-Entwurfsmuster an, um konsistente, wiederverwendbare Schnittstellenverträge zu erstellen, die mit den Beteiligten validiert werden.
4. Wenden Sie ereignisgesteuerte Entwurfsmuster an, um konsistente, wiederverwendbare Schnittstellenverträge zu erstellen, die mit den Beteiligten validiert werden.
5. Wenden Sie GraphQL-Designmuster an, um konsistente, wiederverwendbare Schnittstellenverträge zu erstellen, die mit den Beteiligten validiert werden.
6. Nutzen Sie die Designprinzipien und den API-Styleguide, um Ihre Designentscheidungen an gemeinsamen Regeln auszurichten und eine konsistente Audit-Validierung zu ermöglichen.
7. Wenden Sie Contract-First- oder Design-First-Ansätze an, um den API-Schnittstellenvertrag vor der Implementierung zu erfassen und zu validieren.
8. Verwenden Sie die API-Audit-Checkliste, um sicherzustellen, dass das API-Design funktionale und nicht-funktionale Anforderungen erfüllt, einschließlich Sicherheit, Leistung und Compliance.

## Questions

- Definieren Sie zentrale Entitäten, ihre Attribute und Beziehungen, um ein gemeinsames konzeptionelles Verständnis für alle APIs zu schaffen.
- Verwenden Sie das Interaction Canvas, um zu definieren, wie die Nutzer mit der API interagieren werden, um sicherzustellen, dass sie ihren Bedürfnissen und Erwartungen entspricht.
- Wenden Sie REST-Entwurfsmuster an, um konsistente, wiederverwendbare Schnittstellenverträge zu erstellen, die mit den Beteiligten validiert werden.
- Wenden Sie ereignisgesteuerte Entwurfsmuster an, um konsistente, wiederverwendbare Schnittstellenverträge zu erstellen, die mit den Beteiligten validiert werden.
- Wenden Sie GraphQL-Designmuster an, um konsistente, wiederverwendbare Schnittstellenverträge zu erstellen, die mit den Beteiligten validiert werden.
- Nutzen Sie die Designprinzipien und den API-Styleguide, um Ihre Designentscheidungen an gemeinsamen Regeln auszurichten und eine konsistente Audit-Validierung zu ermöglichen.
- Wenden Sie Contract-First- oder Design-First-Ansätze an, um den API-Schnittstellenvertrag vor der Implementierung zu erfassen und zu validieren.
- Verwenden Sie die API-Audit-Checkliste, um sicherzustellen, dass das API-Design funktionale und nicht-funktionale Anforderungen erfüllt, einschließlich Sicherheit, Leistung und Compliance.
- Bereitstellung von wiederverwendbaren Designmustern, gemeinsamen Standards und Validierungstools für API-Spezifikationen. Sicherstellen, dass Designentscheidungen konsistent, frühzeitig überprüft und auf die Geschäftsabsicht ausgerichtet sind.
- Beim Entwurf von APIs geht es nicht nur um die Benennung von Endpunkten. Gutes Design stellt sicher, dass APIs benutzerfreundlich, konsistent und auf Geschäfts- und technische Ziele ausgerichtet sind. Schlecht gestaltete APIs führen zu enger Kopplung, geringer Wiederverwendung und kostspieligen Nacharbeiten in den Teams.

## Role participation and responsibilities

- [API-Designer](https://apiopscycles.com/de/roles/api-designer.md) (lead): Gestaltet Schnittstellenvertrag, Interaktionsmodell, Konsistenz, Benutzerfreundlichkeit und bereitgestellte Capabilities.
- [API-Produktverantwortlicher](https://apiopscycles.com/de/roles/api-product-owner.md) (core): Steuert API-Chance, Priorisierung und produktbezogene Entscheidungen über den gesamten Lebenszyklus hinweg.
- [Compliance- und Rechtsexperte](https://apiopscycles.com/de/roles/compliance-specialist.md) (core): Klärt rechtliche, Datenschutz-, regulatorische und vertragliche Anforderungen, die Capability, API, Schnittstelle oder Automatisierung betreffen.
- [Domain-Experte](https://apiopscycles.com/de/roles/domain-specialist.md) (core): Bringt tiefes Wissen über Geschäftsdomäne, Konzepte, Regeln und Einschränkungen ein, die die Capability oder Schnittstelle widerspiegeln muss.
- [Sicherheitsspezialist](https://apiopscycles.com/de/roles/security-specialist.md) (core): Stellt sicher, dass Sicherheitsrisiken, Kontrollen und Vertrauensgrenzen über den gesamten Lebenszyklus hinweg berücksichtigt werden.
- [Vertreter der API-Nutzer](https://apiopscycles.com/de/roles/api-consumer-specialist.md) (core): Vertritt die Anforderungen von Entwicklern, Integratoren und anderen Nutzern der API.
- [API-Entwickler](https://apiopscycles.com/de/roles/api-engineer.md) (consulted): Verantwortet Implementierung, Automatisierung, Tests und Release-Abläufe, die für die zuverlässige Bereitstellung der Capability, API oder Automatisierung erforderlich sind.
- [Fachlicher Verantwortlicher](https://apiopscycles.com/de/roles/business-owner.md) (consulted): Vertritt Geschäftsziele, Finanzierung und erwartete Ergebnisse der Capability-, API- oder Automatisierungsinitiative.
- [Plattform-Architekt](https://apiopscycles.com/de/roles/platform-architect.md) (consulted): Leitet Entscheidungen zu Plattform, Integration, Skalierbarkeit und Architektur, die beeinflussen, wie die Capability oder API erstellt und betrieben wird.
- [Verantwortlicher für Dokumentation und DevRel](https://apiopscycles.com/de/roles/api-devrel-specialist.md) (consulted): Verantwortet Onboarding-Inhalte, Entwicklerkommunikation und Dokumentationsqualität für API-Nutzer.

## Resources

- [Interaktions-Canvas](https://apiopscycles.com/de/resources/interaction-canvas.md)
- [REST-Canvas](https://apiopscycles.com/de/resources/rest-canvas.md)
- [Event-Canvas](https://apiopscycles.com/de/resources/event-canvas.md)
- [API Design Prinzipien](https://apiopscycles.com/de/resources/api-design-principles.md)
- [Domänen-Canvas](https://apiopscycles.com/de/resources/domain-canvas.md)