API-Conf Berlin 2019

Die Buzzwords der API-Conf

Im Oktober fand die API-Konferenz in Berlin statt – und wir waren dabei! Alex und Ben haben sich auf den Weg gemacht, um wertvolles Know-How für die API-Entwicklung abzustauben und spannenden Input zu modernem API Design und API Management zu erhalten.

Mitgebracht haben die beiden Power-Wissen, spannende Buzzwords und ganz viele Tipps, die sie den Kollegen in einer internen Schulung vorgestellt haben. Einblick gefällig?

Mitgebracht: Die Buzzwords der API-Conf

Hier gibt es einen kleinen Einblick in die mitgebrachten Buzzwords. Diese Begriffe aus den Bereichen API-Entwicklung, API Design und API Management sollte jeder Entwickler kennen!

HATEAOS

HATEOAS (Hypermedia as the Engine of Application State) ist laut Roy Thomas Fielding, dem US-amerikanischen Informatiker und einem der Hauptautoren der http-Spezifikation, nicht nur eine elementare Eigenschaft in REST-Architekturen, sondern das zentrale REST Constraint.

GraphQL

GraphQL ist eine SQL-ähnliche Abfragesprache inklusive Laufzeitumgebung und Typsystem. Das von Facebook entwickelte (mittlerweile) Open-Source-Projekt kann als REST-Alternative gesehen werden.

„Ist es eine Ablöse von REST oder ein REST-Ersatz? Auf der Konferenz waren sich alle einig: Nein. GraphQL kann aber in bestimmten Use-Cases eine Alternative gegenüber REST sein!“, so Alex, Codeautor der x-root.

Tiger Team

Auch wichtig und ein Teil einiger Konferenz-Talks: Die Zusammenarbeit im Entwickler-Team. In diesem Zusammenhang ist der Begriff „Tiger Team“ gefallen, der das Bilden fester Teams mit einem bestimmten Kernfokus beschreibt.

Ob man hiermit die Gefahr von Inselwissen eingeht? „Nicht, wenn man dem mit regelmäßigen Reviews und einer guten Dokumentation entgegenwirkt.“, meint Alex auf diese Frage.

Magic Estimation

Es wird agil! Fällt es Dir schwer, in Zeit- oder Storypoints zu denken? Magic Estimation sorgt für eine relative Abschätzung des Aufwands von Issues. Der Grundgedanke dahinter ist der, dass der Mensch Relationen leichter auflösen kann als absolute Masse.

„Magic Estimation ist eine gute Art herauszufinden, welche Tickets zu hinterfragen sind.“, David, Codeautor der x-root.

Innovation Tokens

Mithilfe von Innovation Tokens kann ein Unternehmen ein Overkill an Innovationen vermeiden (oft werden in Softwareprojekten viel zu viele Dinge gleichzeitig ausprobiert) und somit das richtige Maß an neuen Technologien in Softwareentwicklungsprojekten finden.

Wie genau das funktioniert, wird in dem Artikel „Gegen Informatikerromantik und Technologieüberflutung: Wie viel Innovation sollen wir zulassen?“ sehr gut erklärt.

Was wir sonst aus der API-Conf mitgenommen haben

Security ist Profisache!

Vor allem, wenn man eine offene API macht, sollte die Security von Profis überprüft werden. Security ist aber auch ein Prozess und muss von vorherein mitbedacht werden.

Die Unterschiede zwischen Academic REST und Pragmatic REST
und das Richardson Maturity Model

Was Entwickler über REST lernen und wie REST tatsächlich umgesetzt wird, da sind teilweise Welten dazwischen! Schlussendlich muss für jeden Anwendungsfall ein Standard gewählt werden, nach dem eine API erstellt wird („Ist meine API RESTful?“) und dieser muss dann fix eingehalten werden.

Richardson Maturity Model

Abhilfe schafft das Maturity Model von Leonard Richardson. Das Richardson Maturity Model ist eine Möglichkeit, die API nach den Constraints von REST zu klassifizieren. Je besser die API die Constraints einhält, desto höher ist ihre Punktzahl.

Level 0 aka „Swamp of PoX“ – Hier liegt strenggenommen keine RESTful API vor

HTTP als Transportsystem
„RPC“-Style
Eine URI
Eine http Methode
Paramter und Rückgabe als Payload

Level 1 aka „Resources“

Individuelle Ressourcen statt Service Endpoint
Mehrere URIs
„eine“ http Methode
Rückgabe als XML/Json/Text Payload

Level 2 aka „Verbs“

„passende“ HTTP Methoden statt nur POST & GET
mehrere URIs
mehrere HTTP Methoden
Rückgabe als Payload & Status Codes

Level 3 aka „Hypermedia“

selbsterklärendes System
nur eine Einstieg-URI bekannt
keine weiteren festen URIs
Rückgabe als Liste von neuen „Möglichkeiten“

Um einen Anhaltspunkt zu haben: Level 2 ist für uns das absolute Minimum für eine REST API. Level 3 – also HATEOAS – bietet viele Möglichkeiten, die aber auch aufwendig in der Umsetzung sind.

Natürlich würde ein umfangreicher Einblick in alle Learnings aus der Konferenz hier den Rahmen sprengen (große Themen wie Dokumentation mit Open API, Filter, Pagination, Sorting u.v.m – es gibt viel zu erzählen!), aber Du kannst jederzeit Deine Fragen in die Kommentare schreiben und wir schauen mal, ob wir Dir Deine Fragen beantworten können!

Übrigens, wenn Du richtig Lust hast, in einem coolen Team zu arbeiten, Dich regelmäßig auf Konferenzen weiterzubilden und dank interner Schulungen immer Up-To-Date zu bleiben, dann schau doch mal in unsere Stellenanzeigen. 😉