Thoughts on agile software development
Bei der Verwendung von REST Schnittstellen beginnt die Evolution eigener APIs mit der Erstellung einiger HTTP Endpunkte die Informationen im JSON Format austauschen. Die nächste Stufe ist die Abkehr von der Denkweise in Aktionen hin zum Verständnis, dass über REST Resourcen addressiert und manipuliert werden.
Die Dokumentation einer REST API sieht immer sehr schick aus. Ob es sich um eine interaktive Swagger Seite handelt oder um eine statische Darstellung eines anderen Tools, alle Endpoints, Parameter und Datentypen sind akkurat aufgelistet.
In den Beiträgen REST in Peace und REST heißt HATEOAS wurde schon auf die Möglichkeiten des HATEOAS Patterns hingewiesen. Die Verlinkung von Resourcen nutzen um innerhalb der Client Anwendung das notwendige Wissen um die Server API zu reduzieren, entkoppelt Systeme und vereinfacht die Entwicklung und Wartung. Auch in diesem Beitrag wird es um die Implementierung … Read more
Im Zuge der Implementierung einer Restschnitstelle für die Verwaltung von Ahnenfoschungsvereinen kam die Frage auf, ob man die Datenbankabfragen nicht cachen könnte. Da der Bestand an solchen Vereinen sich selten verändert, liefert dieser Mikroservice fast immer identische Ergebnisse.
Häufig existieren REST Schnittstellen, die Resourcen im Json Formate zurückliefern, die keinerlei Verknüpfung zu anderen Resourcen besitzen. Schlimmer noch, sie offenbaren interne Werte, damit der Client die Möglichkeit hat, andere Resourcen zu adressieren oder zu manipulieren. Häufig ist es dies der Schlüssel der Resourcen in der Datenbank.