1. Eine gute REST‑API zu designen ist ohne ein gutes Domain Model nur schwer möglich.

2. Microservices können als System von Systemen betrachtet werden und zeigen als solche parallelen zum Internet. So sind oder sollen, sowohl Internet, als auch Microservices skalierbar sein und es gut verkraften, wenn einzelne (Teil‑) Systeme auftauchen, ausfallen oder sich verändern.

3. Allgemein zu Codebeispielen, diese seien üblicherweise zu speziellen Sachverhalten formuliert. Alle anderen Themen seien meist so modelliert, dass sie so wenig Reibung als nötig erzeugten und damit oftmals nicht ideal.

4. Eine REST‑API erlaubt grundsätzlich ausschließlich den Zugriff auf eine Repräsentation der jeweiligen Objekte.

5. Der entscheidende Teil einer HTTP‑API ist die Frage, was in der Repräsentation der übertragenen Objekte steckt, damit der Client etwas Sinnvolles damit anfangen kann. Im Gegensatz dazu ist die konkrete Benennung der URIs einer HTTP‑API ein weniger entscheidendes Problem, auf das manchmal unnötig viele Resourcen verwendet werden.

6. Bei der praktischen Implementierung der API mit Spring gilt es zu beachten, dass Verknüpfungen zwischen Aggregaten am besten ausschließlich über ID‑Verbindungen erfolgen, da es ansonsten zu rekursiven Beziehungen kommen kann, welche die Repräsentation unnötig aufblähen.

7. Ein wichtiger Aspekt des Domain Driven Design besteht darin, implizite Dinge explizit zu darzustellen.

8. REST ist fachlich orientiert und darauf konzentriert, welche individuellen Konzepte, welche Aktionen benötigen. Dabei unterstützen diese Ressourcen im Wesentlichen alle dieselben Operationen die sich hauptsächlich in ihrer Idempotenz unterscheiden. Idempotenz bedeutet dabei, dass das Ergebnis für die Ressource gleich ausfällt, nicht zwangsläufig, dass die gleichen Tätigkeiten ausgeführt werden oder Resultate zurückgegeben werden.

9. Langlaufende Prozesse in REST können modelliert werden, indem ein solcher Prozess als Ressource behandelt wird. Diese wird initial angelegt (häufig mittels eines POST‑Requests) und nach Abschluss des Prozesses wieder entfernt (häufig mittels DELETE‑Request).

10. Bei der Repräsentation ist darauf zu achten, dass Verweise auf andere Ressourcen vom Server geliefert werden (in Form von URI Links, oder konkreten Templates), Clients sollten URIs nicht eigenständig „raten“. Eine konkrete Möglichkeit, da zum Beispiel JSON kein Link Konzept kennt, dafür ist HAL (Hypertext Application Language). Links stellen im Rahmen von REST das fundamentale statische Integrationskonzept dar.

11. Mit Microservices soll erreicht werden das unabhängig von allen anderen Systemen neue Versionen ausgeliefert werden können. Dabei besteht die Minimalforderung die Kopplung so lose zu Gestalten das andere Systeme dabei nicht brechen. Gleichzeitig erfordert dies eine sorgfältiges API‑Design, da Refactoring in solchen Systemen nur schwer umzusetzen ist.

12. Das Abstraktionslevel einer API sollte ausreichend hoch sein um Domain Logik und Geschäftsprozesse zu modellieren, dadurch wird die Anwendung flexibel und Logik muss nicht in den Client repliziert werden. Eine API sollte sich fernerhin durch „evolvability“ auszeichnen um Änderungen implementieren zu können.

13. Eine Zielvorstellung ist es eine API zu gestalten bei der ein Client neue Features „lernen“ kann ohne das er verändert werden müsste. Zusätzlich zu API‑Links soll der Client erfahren, welche Möglichkeiten es gibt weiter zu verfahren und diese Möglichkeiten dann dynamisch anbieten. (Hypermedia as the engine of Application state)

(Rechtsklick -> Ziel speichern unter)

Kernaussagen (PDF)