isaqb-org · sippsack · Jan 15, 2025 · Dec 16, 2024 · Dec 16, 2024 · Dec 16, 2024
diff --git a/docs/00b-basics/01-what-to-expect-of-this-module.adoc b/docs/00b-basics/01-what-to-expect-of-this-module.adoc
@@ -8,11 +8,18 @@ Das Modul betrachtet die verschiedenen Arten, wie APIs Wert erzeugen: Als techni
 Im Rahmen dieses Moduls sprechen wir bei APIs immer von Netzwerk-basierten Schnittstellen, also nicht von lokalen Programmierschnittstellen.
 
 Neben dem Schwerpunkt auf technischem Themen werden auch strategische Aspekte behandelt wie die Wertschöpfung und die Verwendungen von APIs als Team-Kollaboration im Unternehmen. Damit eignet sich das Modul gut, um sich dem Thema APIs mit einer weiteren Perspektive als dem rein technischen Blick zu nähern.
+
 // end::DE[]
 
 // tag::EN[]
 === What does the module “{curriculum-short}” convey?
 
-The module presents {curriculum-short} to the participants …
-At the end of the module, the participants know … and are able to …
+Application Programming Interfaces, or APIs, enable the use of digital services via programmable interfaces. Their use has increased significantly over the last 20 years. From a software architecture perspective, APIs are relevant from both a producer and consumer point of view: Software components should ideally be understood as reusable products; APIs help to make a software component easily reusable. Today, more and more services are available via APIs. As a consumer of these services, it is easier to concentrate on core tasks and outsource other tasks to external components.
+
+The module looks at the different ways in which APIs create value: as technical interfaces that allow different components to communicate with each other; as organisational interfaces that allow different teams to develop their respective components with fewer interdependencies; and as business-oriented building blocks that allow the organisation to develop new services faster and more effectively.
+
+In this module, we always refer to APIs as network-based interfaces, i.e. not as local programming interfaces.
+
+In addition to the focus on technical topics, strategic aspects such as value creation and the use of APIs as team collaboration in the company are also covered. The module is therefore well suited to approaching the topic of APIs from a broader perspective than a purely technical one.
+
 // end::EN[]
diff --git a/docs/00b-basics/02-curriculum-structure-and-chronological-breakdown.adoc b/docs/00b-basics/02-curriculum-structure-and-chronological-breakdown.adoc
@@ -44,27 +44,60 @@
 |
 
 | Summe
-| 600 (10 h)
-| 240 (4 h)
+| 540 (9 h)
+| 180 (3 h)
 |===
 
 // end::DE[]
 
 // tag::EN[]
 === Curriculum Structure and Recommended Durations
 
-[cols="<,>", options="header"]
+[cols="<,>,>", options="header"]
 |===
 | Content
 | Recommended minimum duration (minutes)
-| 1. Introduction | 180
-| 2. xz | 150
-| 3. Lots of theory | 120
-| 4. xy and example | 180
-| 5. abc und d | 210
-| 6. Final example | 120
-| |
-| Total | 960 (16h)
+| Übungszeit (Minuten)
+
+| 1. Why APIs are Important
+| 60
+| 0
+
+| 2. How APIs are Creating Value
+| 60
+| 30
+
+| 3. API Styles and Technologies
+| 60
+| 30
+
+| 4. API Design
+| 90
+| 30
+
+| 5. Description of APIs
+| 90
+| 30
+
+| 6. API Lifecycle and API Tooling
+| 60
+| 30
+
+| 7. API Security
+| 60
+| 30
+
+| 8. APIs at Scale: Platforms and Governance
+| 60
+| 0
+
+|
+|
+|
+
+| Total
+| 540 (9 h)
+| 180 (3 h)
 
 |===
 

diff --git a/docs/00b-basics/04-prerequisites-for-this-training.adoc b/docs/00b-basics/04-prerequisites-for-this-training.adoc
@@ -2,25 +2,20 @@
 === Voraussetzungen
 
 Teilnehmerinnen und Teilnehmer **sollten** folgende Kenntnisse und/oder Erfahrung mitbringen:
+
 - Architekten
 - Entwickler
 - andere technisch orientierte Personen, die sich einen umfassenden Überblick über das Thema APIs verschaffen möchten.
+
 // end::DE[]
 
 // tag::EN[]
 === Prerequisites
 
-Participants **should** have the following prerequisite knowledge:
-
-- Prerequisite 1
-- Prerequisite 2, etc.
+Participants **should** have the following knowledge and/or experience:
 
-Knowledge in the following areas may be **helpful** for understanding some concepts:
+- Architects
+- Developers
+- other technically orientated people who would like to gain a comprehensive overview of the topic of APIs.
 
-- Area 1:
-  * Knowledge 1
-  * Experience 2
-  * Knowledge 3
-  * Experience 4
-  * Understanding 5
 // end::EN[]
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
@@ -1,6 +1,6 @@
 // tag::DE[]
 |===
-| Dauer: 60 Min. | Übungszeit: 30 Min.
+| Dauer: 90 Min. | Übungszeit: 30 Min.
 |===
 
 === Begriffe und Konzepte
@@ -11,10 +11,10 @@ API Economy, API Wertschöpfung, API Business Models, Digitale Transformation
 
 // tag::EN[]
 |===
-| Duration: 60 min | Practice time: 30 min
+| Duration: 90 min | Practice time: 30 min
 |===
 
 === 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[]