Intuitive APIs

APIs dienen verschiedenen Zwecken. Im einfachsten Fall dienen sie dazu, dass zwei technologisch verschiedene Komponenten eines verteilten Systems interagieren können. In Microservice-Architekturen können sie als zusätzliche Ebene eingeführt werden, um die Interaktion uniformer zu gestalten und einer bestimmten Domänen-Sprache zu folgen. Die architektonisch aufwändigsten APIs sind diejenigen, an denen sich manifestiert, welche Funktionalität ein spezifischer Service anbietet. Diese definieren nicht nur ein Interaktionsmuster, sondern auch die eindeutige Semantik aller Ressourcen und Aktionen.

Im letzten SITIC Online Sharing haben wir über den Schnitt in Microservices gesprochen. Diesmal wollen wir uns genauer mit API-Design befassen, nicht nur im Kontext von Microservice-Architekturen, sondern auch für klassische Monolithen. Dabei wollen wir Unterschiede herausarbeiten, welche für die Architektur von internen APIs, Public Facing APIs oder auch APIs zu (externen) Portalen wichtig sind. Eine Schlüsselfrage dabei lautet: Wie gelingt ein intuitives API Design das zugleich erweiterbar bleibt?

Schließlich sind APIs auch oft die Kommunikationsgrundlage zwischen Teams. Mit dem passenden Design-Ansatz entstehen intuitive APIs, die viele Missverständnisse zwischen Architekten, Entwicklern und Benutzern vermeiden.

• Wann verwenden wir ressourcen-orientierte (REST) APIs, wann prozess-orientierte APIs (RPC), wann Query-Sprachen wie GraphQL?
• Welchen Best-Practices folgen wir im Architekturmodell REST bezüglich
  – Query-Design,
  – Daten-Validierung,
  – HATEOAS (mit Hypermedia Formaten wie HAL, Collection+JSON oder JSON-API)?
• Welche Methoden zur Typisierung von Entitäten bewähren sich?
• In welchen Szenarien sind welche Ansätze für Paginierung (wie Limit/Offset, Cursor) sinnvoll?
• Wie versionieren wir
  – verschiedene Versionen von Entitäten,
  – Änderungs-Historien?
• Wie testen wir APIs effektiv?

Von den Teilnehmenden wird erwartet, dass sie sich anhand eines Fragenkatalogs vorbereiten. Die Fragen werden ihnen zusammen mit der Teilnahmebestätigung zugestellt.

Willkommen sind Business IT Professionals, welche im Unternehmen Aufgaben der Digitalisierung, IT-Architektur oder DevOps wahrnehmen.

Fachliche Moderation: Simon Wehrli
Technische Moderation: Florence Neumann

• (20’) Einführung: Wir schauen uns anhand von API Definitionen an, wie man Eigenschaften einer RESTful API auch in RPC übertragen kann, um die Unterschiede zwischen den Architekturmodellen und den tatsächlichen Eigenschaften einer API zu verdeutlichen.
• (60’’) Diskussion präferenzierter Fragen
• (20’) Interaktive Sammlung der Erkenntnisse
• (20’) Priorisierung der Key-Takeaways

Die Nachlese umfasst eine Gegenüberstellung des Status quo mit den gewonnenen Erkenntnissen und zeigt Aktions-Potentiale auf.

Verbindliche Anmeldung bitte via Email an kurt.wehrli@sitic.org

Für SITIC-Mitglieder ist die Teilnahme im Rahmen der Jahresmitgliedschaft unentgeltlich.
Nicht-Mitgliedern werden 375 CHF in Rechnung gestellt, der Zahlungseingang muss vor dem Sharing erfolgen.

Die Abkürzung “HATEOAS” steht für “Hypermedia As The Engine Of Application State”.

Dieser Begriff beschreibt eine der entscheidenden REST-Eigenschaften: Da der Architekturstil eine universelle Schnittstelle bieten soll, fordert HATEOAS nämlich, dass der REST-Client sich ausschließlich durch das Folgen von URIs (Uniform Resource Identifier) im Hypermedia-Format durch die Webanwendung bewegen kann … [Mehr]

Microservices sind ein Architekturkonzept der Anwendungsentwicklung. Was sie von herkömmlichen, monolithischen Ansätzen unterscheidet, ist die Art und Weise, wie Apps in ihre Kernfunktionen aufgeschlüsselt werden. Jede Funktion bzw. jeder Service kann unabhängig entwickelt und implementiert werden. Das heißt, individuelle Services können ohne jegliche Beeinflussung anderer Services funktionieren (oder auch nicht).
Referenz

Microservices – also known as the microservice architecture – is an architectural style that structures an application as a collection of services that are

• Highly maintainable and testable
• Loosely coupled
• Independently deployable
• Organized around business capabilities
• Owned by a small team.

The microservice architecture enables the rapid, frequent and reliable delivery of large, complex applications.
It also enables an organization to evolve its technology stack.
Reference