isaqb-org · sippsack · Jan 15, 2025 · Dec 16, 2024 · Dec 16, 2024 · Dec 16, 2024
diff --git a/docs/01-why-apis/00-structure.adoc b/docs/01-why-apis/00-structure.adoc
@@ -8,7 +8,7 @@
 // end::DE[]
 
 // tag::EN[]
-== Why APIs are important
+== Why APIs are Important
 // end::EN[]
 
 

diff --git a/docs/01-why-apis/01-duration-terms.adoc b/docs/01-why-apis/01-duration-terms.adoc
@@ -10,9 +10,10 @@ Lokale APIs, Netzwerk-basierte APIs, API Landschaft, Systemintegration
 
 // tag::EN[]
 |===
-| Duration: XXX min | Practice time: XXX min
+| Duration: 60 min | Practice time: 0 min
 |===
 
 === Terms and Principles
-Term 1, Term 2, Term 3
+Local APIs, Network-Based APIs, API landscape, Systems Integration
+
 // end::EN[]
diff --git a/docs/01-why-apis/02-learning-goals.adoc b/docs/01-why-apis/02-learning-goals.adoc
@@ -21,6 +21,19 @@ Unterschiedliche Ansätze zur Systemintegration sind den Teilnehmer:innen bekann
 
 // tag::EN[]
 [[LG-1-1]]
-==== LG 1-1: The is the first learning goal, in category xy
-tbd.
+==== LG 1-1: Understand APIs in the Context of Software Development
+
+Participants understand APIs in the context of programming, computer networks, distributed systems, and software architecture.
+They understand the development from local APIs to network-based APIs and the current API landscape in the overall context.
+
+[[LG-1-2]]
+==== LG 1-2: Compare different Styles and Concepts of Integration
+
+Different approaches for systems integration are known to participants and can be compared and contrasted, specifically:
+
+* Integration through a shared database
+* File-based systems integration
+* Integration through synchronous communications, for example RPC (Remote Procedure Call)
+* Integration through asynchronous communications, for example message queues
+
 // end::EN[]
diff --git a/docs/02-api-value/01-duration-terms.adoc b/docs/02-api-value/01-duration-terms.adoc
@@ -15,6 +15,6 @@ API Economy, API Wertschöpfung, API Business Models, Digitale Transformation
 |===
 
 === Terms and Principles
-Term 1, Term 2, Term 3
+API economy, API value creation, API business models, Digital Transformation
 
 // end::EN[]
diff --git a/docs/02-api-value/02-learning-goals.adoc b/docs/02-api-value/02-learning-goals.adoc
@@ -30,7 +30,30 @@ Teilnehmer:innen können APIs einordnen in das grössere Bild digitaler Transfor
 // end::DE[]
 
 // tag::EN[]
-[[LG-1-1]]
-==== LG 1-1: The is the first learning goal, in category xy
-tbd.
+[[LG-2-1]]
+==== LG 2-1: Understand the "API Economy"
+
+Participants understand the broader concept of the "API Economy" and understand how their products and activities fit into it.
+
+[[LG-2-2]]
+==== LG 2-2: Know Various Ways of API Value Creation
+
+Participants know and understand the various ways in which APIs can help with value creation. On the top level, the different ways can be categorized into three areas:
+
+* Private APIs which are used inside an organization
+* Partner APIs which are used with established partners
+* Public APIs which are offered as products to the general public
+
+Participants understand the various options inside these categories and the relationships between them. They also understand how a comprehensive API strategy adds value for all of these categories.
+
+[[LG-2-3]]
+==== LG 2-3: Understand API Business Models
+
+Participants have a detailed knowledge of the various business models for APIs and know a few specific examples. Starting from these different business models participants understand how to analyze existing business models and how they can be augmented with APIs.
+
+[[LG-2-4]]
+==== LG 2-4: Understand APIs and Digital Transformation
+
+Participants know how to fit APIs into the bigger picture of digital transformation. APIs are identified as necessary (but not sufficient) aspect of digital transformation, and other necessary aspects are known as well.
+
 // end::EN[]
diff --git a/docs/03-api-styles/01-duration-terms.adoc b/docs/03-api-styles/01-duration-terms.adoc
@@ -15,6 +15,6 @@ RPC, Ressource, Hypermedia, Query, Events, asynchrone Kommunikation, gRPC, HTTP
 |===
 
 === Terms and Principles
-Term 1, Term 2, Term 3
+RPC, resource, hypermedia, query, events, asynchronous communications, gRPC, HTTP APIs, REST, GraphQL
 
 // end::EN[]
diff --git a/docs/03-api-styles/02-learning-goals.adoc b/docs/03-api-styles/02-learning-goals.adoc
@@ -4,7 +4,7 @@
 [[LZ-3-1]]
 ==== LZ 3-1: Grundlegende API-Stile verstehen
 
-Die folgenden API-Stile werden erläutert und ihre Vor- sowie Nachteile gegeneinander abgewogen:
+Die folgenden API-Stile werden verstanden und ihre Vor- sowie Nachteile können gegeneinander abgewogen werden:
 
 * RPC (Remote Procedure Call)
 * Resourcen-basiert
@@ -15,7 +15,7 @@ Die folgenden API-Stile werden erläutert und ihre Vor- sowie Nachteile gegenein
 [[LZ-3-2]]
 ==== LZ 3-2: Populäre API-Technologien ein- und den jeweiligen API-Stilen zuordnen
 
-Teilnehmer:innen können die wichtigsten populären API-Technologien einordnen und kennen den von ihnen implementierten API-Stil, z. B.:
+Teilnehmer:innen können die wichtigsten populären API-Technologien einordnen und kennen den von ihnen implementierten API-Stil, z.B.:
 
 * gRPC
 * HTTP APIs
@@ -31,10 +31,29 @@ Teilnehmer:innen erwerben ein Verständnis für Kriterien, wann welche Stile/Tec
 
 // tag::EN[]
 [[LG-3-1]]
-==== LG 3-1: TBD
-tbd.
+==== LG 3-1: Understand Fundamental API Styles
+
+The following API styles are understood by participants and their advantages and drawbacks can be compared:
+
+* RPC (Remote Procedure Call)
+* Resource-based
+* Hypermedia
+* Query
+* Events & asynchronous communications
 
 [[LG-3-2]]
-==== LG 3-2: TBD
-tbd.
+==== LG 3-2: Understand Popular API Technologies and Associating Them With API Styles
+
+Participants are able to classify the most important API technologies and know which API style they are implementing, for example:
+
+* gRPC
+* HTTP APIs
+* REST
+* GraphQL
+
+[[LG-3-3]]
+==== LG 3-3: Understand When to Use Which Style and Technology and the Consequences of That Choice
+
+Participants gain knowledge of criteria when certain styles and technologies are a good or not-so-good fit, and which consequences the selection will have.
+
 // end::EN[]
diff --git a/docs/04-api-design/01-duration-terms.adoc b/docs/04-api-design/01-duration-terms.adoc
@@ -4,7 +4,7 @@
 |===
 
 === Begriffe und Konzepte
-Design von APIs, API First, konsumentengetriebenes API-Design, Postel's Law, Forward und Backward Compatibility, Versionierung und Lebenszyklus von API Produkten, JSON:API, API Design Style Guides
+Design von APIs, API First, konsumentengetriebenes API-Design, Postel's Law, Forward und Backward Compatibility, Versionierung und Lebenszyklus von API Produkten, JSON:API, HAL, API Design Style Guides
 
 // end::DE[]
 
@@ -14,5 +14,6 @@ Design von APIs, API First, konsumentengetriebenes API-Design, Postel's Law, For
 |===
 
 === Terms and Principles
-Term 1, Term 2, Term 3
+API design, API First, consumer-driven API design, Postel's Law, Forward and backward compatibility, Versioning and lifecycle of API products, JSON:API, HAL, API design style guides
+
 // end::EN[]
diff --git a/docs/04-api-design/02-learning-goals.adoc b/docs/04-api-design/02-learning-goals.adoc
@@ -4,14 +4,14 @@
 [[LZ-4-1]]
 ==== LZ 4-1: Bedeutung von API Design verstehen
 
-Teilnehmer:innen verstehen, weshalb ein gewissenhaftes Design von API-Schnittstellen von großer Bedeutung ist und welchen Einfluss dies auf die Nutzbarkeit, Wartung, Weiterentwicklung und Verbreitung der Schnittstelle haben wird.
-
+Teilnehmer:innen verstehen, weshalb ein gewissenhaftes Design von API-Schnittstellen von großer Bedeutung ist und welchen Einfluss dies auf die Nutzbarkeit, Wartung, Weiterentwicklung und Verbreitung haben wird.
 
 [[LZ-4-2]]
 ==== LZ 4-2: API Design als "Outside-in" Ansatz anwenden
 
 Zu den wichtigsten Zielen von APIs zählt die effiziente Anbindung von Konsumenten an die Schnittstelle des Betreibers.
-Das Design sollte auf die Anforderungen der Konsumenten fokussiert sein und nicht entlang eventuell bestehender Systeme, Use Cases oder Datenbanken. Teilnehmer:innen kennen und verstehen die Ansätze von API First und konsumentengetriebenem API-Design.
+Das Design sollte auf die Anforderungen der Konsumenten fokussiert sein und nicht entlang eventuell bestehender Systeme, Use Cases oder Datenbanken.
+Teilnehmer:innen kennen und verstehen die Ansätze von API First und konsumentengetriebenem API-Design.
 
 [[LZ-4-3]]
 ==== LZ 4-3: Offenheit und Erweiterbarkeit als wichtige Aspekte für die Weiterentwicklung von APIs interpretieren
@@ -32,24 +32,56 @@ Teilnehmer:innen erlangen ein Verständnis für verschiedene Aspekte der Version
 ==== LZ 4-5: Good Practices für gelungenes API Design kennen
 
 Teilnehmer:innen lernen bewährte und verbreitete Ansätze für das Design von HTTP APIs kennen und verstehen die Vorteile und Herausforderungen.
-
-Hierzu zählen u. a.:
+Hierzu zählen u.a.:
 
 * URL-Pfade
 * korrekte Verwendung von HTTP-Methoden oder Operationen für häufig benötigte Funktionalität wie Suchen, Filtern oder Sortieren
-* Formatvorschläge wie JSON:API
+* Formatvorschläge wie JSON:API oder HAL
 * Problem Details for HTTP APIs (RFC 9457)
-* API Design Style Guides <<geewax>>
+* API Design Style Guides
 
 
 // end::DE[]
 
 // tag::EN[]
 [[LG-4-1]]
-==== LG 4-1: TBD
-tbd.
+==== LG 4-1: Understand the Significance of API Design
+
+Participants understand why careful API design is important and which influence it has on usability, maintenance, evolution, and adoption.
 
 [[LG-4-2]]
-==== LG 4-2: TBD
-tbd.
+==== LG 4-2: Use the "outside-in" Approach for API Design
+
+One of the most important goals of APIs is to efficiently connect consumers with the provider's interface.
+API design should be focused on the needs of the consumers.
+It shouldn't be based on existing systems, existing use cases, or databases.
+Participants know and understand the approaches of API First and consumer-oriented API design.
+
+[[LG-4-3]]
+==== LG 4-3: Understand Openness and Extensibility as Important Aspects for API Evolution
+
+Participants understand Postel's law, the concepts of forward and backward compatibility, and the importance of these concepts for the evolution of APIs.
+Participants also understand the consequences for API implementation in strong and statically typed languages.
+
+[[LG-4-4]]
+==== LG 4-4: Understand API Versioning
+
+Participants gain knowledge for various aspects of versioning and how these are applied during the lifecycle of an API product. The following concepts are known:
+
+* Compatibility and the difference between forward and backward compatibility
+* Version identification in general and semantic versioning as a specific model for version identification
+* Different ways of version identification for APIs (for example, domain name, URI path, HTTP header, payload-based)
+
+[[LG-4-5]]
+==== LG 4-5: Know Good Practices for API Design
+
+Participants learn about established and widely used aspects for API design and understand their advantages and challenges.
+These aspects include:
+
+* URL paths
+* Using correct HTTP methods or operations for frequently needed functionality such as searching, filtering, or sorting
+* Proposed formats such as JSON:API or HAL
+* Problem Details for HTTP APIs (RFC 9457)
+* API Design Style Guides
+
 // end::EN[]
diff --git a/docs/05-api-description/01-duration-terms.adoc b/docs/05-api-description/01-duration-terms.adoc
@@ -4,7 +4,7 @@
 |===
 
 === Begriffe und Konzepte
-API-Beschreibung, OpenAPI, GraphQL, gRPC, AsyncAPI, IDL
+API-Beschreibung, OpenAPI, Protocol Buffers, AsyncAPI, GraphQL, gRPC, IDL
 
 // end::DE[]
 
@@ -14,6 +14,6 @@ API-Beschreibung, OpenAPI, GraphQL, gRPC, AsyncAPI, IDL
 |===
 
 === Terms and Principles
-Term 1, Term 2, Term 3
+API description, OpenAPI, Protocol Buffers, AsyncAPI, GraphQL, gRPC, IDL
 
 // end::EN[]
diff --git a/docs/05-api-description/02-learning-goals.adoc b/docs/05-api-description/02-learning-goals.adoc
@@ -19,8 +19,8 @@ Die generellen Strukturen von JSON und YAML sind bekannt.
 
 Teilnehmer:innen verstehen die Hauptelemente einer OpenAPI Beschreibung und wie diese für konkrete APIs verwendet werden.
 
-* Resourcen (Paths)
-* Interaktionen
+* Ressourcen (Paths)
+* Interaktionen (Operations)
 * Repräsentationen
 * Mechanismen wie Tags, Security, Components und Webhooks
 
@@ -38,10 +38,28 @@ OpenAPI ist spezialisiert auf HTTP APIs. Für andere API-Stile können alternati
 
 // tag::EN[]
 [[LG-5-1]]
-==== LG 5-1: TBD
-tbd.
+==== LG 5-1: Understand the Significance of API Descriptions
+
+Participants understand the value of API descriptions and understand the various stakeholders. The problem of "API Drift" is known. Participants understand the relationship between design, implementation, versioning, description, and description versioning, and they understand how these concepts relate ideally and in real-world scenarios.
 
 [[LG-5-2]]
-==== LG 5-2: TBD
-tbd.
+==== LG 5-2: Understand OpenAPI as a Description Language for HTTP APIs
+
+Participants understand OpenAPI as a description language that is specialized for HTTP-based APIs. They understand the history of OpenAPI and how the various versions evolved. Participants understand how to use OpenAPI for code generation both on the provider side and on the consumer side. The overall structure of JSON and YAML is understood.
+
+[[LG-5-3]]
+==== LG 5-3: Understand OpenAPI's Structure
+
+Participants understand the main elements of an OpenAPI description and how to use these for describing concrete APIs.
+
+* Resources (Paths)
+* Interactions (Operations)
+* Representations
+* Mechanisms such as Tags, Security, Components, and Webhooks
+
+[[LG-5-4]]
+==== LG 5-4: Understand Alternative Description Languages
+
+OpenAPI is specialized for HTTP-based APIs. For other API styles, it is possible to use alternative descriptions languages that have the same general goals. Participants know these alternative description languages and can associate them with API styles.
+
 // end::EN[]
diff --git a/docs/06-api-lifecycle/01-duration-terms.adoc b/docs/06-api-lifecycle/01-duration-terms.adoc
@@ -15,6 +15,7 @@ API Lifecycle, API Produkt, Linting, Contract Testing, API Gateway
 |===
 
 === Terms and Principles
-Term 1, Term 2, Term 3
+
+API lifecycle, API product, linting, contract testing, API gateway
 
 // end::EN[]
diff --git a/docs/06-api-lifecycle/02-learning-goals.adoc b/docs/06-api-lifecycle/02-learning-goals.adoc
@@ -25,10 +25,23 @@ Teilnehmer:innen können mit einigen dieser Tools praktisch arbeiten und versteh
 
 // tag::EN[]
 [[LG-6-1]]
-==== LG 6-1: TBD
-tbd.
+==== LG 6-1: Understand the API Lifecycle
+
+Participants understand the various stages of the development cycle of an API product and the typical tasks that are performed throughout these stages.
+Participants understand the the various stages of planning, requirements analysis, design, prototyping, development, testing, quality assurance, deployment, publication, operations, and maintenance, and how to improve an API product in an iterative way.
+Participants also now the different lifecycle stages of an API such as prototype, production, deprecation, and sunsetting.
 
 [[LG-6-2]]
-==== LG 6-2: TBD
-tbd.
+==== LG 6-2: Manage APIs as Products
+
+APIs are often used in loosely coupled scenarios and for this reason it makes sense to manage them as products.
+Participants understand what it means to manage an API as a product.
+API product management starts with focus on a set of consumers, deals with questions of usability, includes feedback, and also handles questions of deprecation and how to provide alternatives.
+
+[[LG-6-3]]
+==== LG 6-3: Know API Lifecycle Tooling
+
+Participants know typical tools that are used throughout the API lifecycle. These tools support producers as well as consumers and include functionality such as linting, testing (e.g., contract testing) and mocking, and operations (API gateways).
+Participants gain practical knowledge of some of these tools and understand how they fit into the bigger picture of API lifecycle tooling.
+
 // end::EN[]
diff --git a/docs/07-api-security/02-learning-goals.adoc b/docs/07-api-security/02-learning-goals.adoc
@@ -16,10 +16,14 @@ Teilnehmer:innen verstehen, wie HTTPS, HTTP-Authentisierung, OAuth und OpenID Co
 
 // tag::EN[]
 [[LG-7-2]]
-==== LG 7-2: TBD
-tbd.
+==== LG 7-2: Understand Communications Security Fundamentals
+
+Participants understand the foundations of communications security and are able to relate them to technologies such as TCP, HTTP, and TLS.
+Participants understand the relevance of secure communications, even in the case of internal interfaces.
 
 [[LG-7-2]]
-==== LG 7-2: TBD
-tbd.
+==== LG 7-2: Understand Security Technologies for APIs
+
+Participants understand HTTPS, HTTP authentication, OAuth, and OpenID Connect, how they relate and differ, and how these technologies help when it comes to securing APIs.
+
 // end::EN[]
diff --git a/docs/08-api-governance/01-duration-terms.adoc b/docs/08-api-governance/01-duration-terms.adoc
@@ -15,6 +15,7 @@ Internal Developer Platform (IDP), API Plattform, Business Plattform, API Guidel
 |===
 
 === Terms and Principles
-Term 1, Term 2, Term 3
+
+Internal developer platform (IDP), API platform, business platform, API guidelines, API design platform, self service
 
 // end::EN[]