Hier ist, wie es in den letzten Jahren aussah:<\/p>\n\n\n\n
sowie an einigen Back-Ends (Java, Python, CF, Node.js etc.), die REST-API-Endpunkte bereitstellen.<\/p>\n\n\n\n
Dieses Setup verschiebt eine Vielzahl von Daten, Abruf und Verarbeitungscode vom Back-End \u201cBE\u201d (Webserver) zum Front-End \u201cFE\u201d (Webbrowser, mobile App). Es erleichtert die Entwicklung am Back-End, erh\u00f6ht aber die Komplexit\u00e4t am Front-End enorm. Hinzu kommt, dass es eine Reihe neuer Probleme mit der API-Kompatibilit\u00e4t gibt.<\/p>\n\n\n\n
In der Theorie sollte die REST-API nur Vorteile haben, die Folgendes beinhalten:<\/p>\n\n\n\n
Aber in der Praxis (und Praxis schl\u00e4gt immer die Theorie in der IT) verursacht sie f\u00fcr die meisten Entwicklerteams vor allem gro\u00dfe Probleme mit der Dateninkompatibilit\u00e4t auf REST-API-Endpunkten.<\/p>\n\n\n\n
Diese Probleme versch\u00e4rfen sich mit mehreren Back-End-Schritten (z.B. Microservices) BE->BE->FE und umgekehrt beim Schreiben von Daten FE<-BE<-BE, was zu unn\u00f6tigen Stunden f\u00fcr alle Entwickler und zu Frustration von Kunden\/Produktinhabern f\u00fchrt.<\/p>\n\n\n\n
Noch schlimmer ist, dass API-Teile von Teams in einem anderen B\u00fcro\/Land entwickelt wurden<\/strong> – Stunden werden zu Tagen und Wochen verschwendet.<\/p>\n\n\n\n Diese Unterschiede ergeben sich aus realen Situationen wie z.B:<\/p>\n\n\n\n Allgemeinen hilft es, wenn Sie einige REST-API-Designrichtlinien befolgen<\/strong> (z.B. dies oder das). Aber es wird nicht alle der oben genannten Probleme vollst\u00e4ndig l\u00f6sen. Normalerweise k\u00f6nnen wir nicht alle Teile der API in gro\u00dfen Systemen kontrollieren. So bleibt Ihr Leitfaden „auf dem Papier“ und hat in der Praxis keine Bedeutung. Au\u00dferdem gibt es keine automatische M\u00f6glichkeit, zu \u00fcberpr\u00fcfen, ob die API den gew\u00e4hlten Richtlinien entspricht, da es sich nur um Artikel in menschlicher Sprache handelt. Neben der Einhaltung einer Richtlinie m\u00fcssen sich Ihre API-Endpunkte auf beiden Seiten einigen.<\/p>\n\n\n\n Wir brauchen etwas, auf das wir uns verlassen k\u00f6nnen – eine Dokumentation, die sich selbst automatisch testet und das Problem sofort und automatisch verfolgt, im Gegensatz zu einer manuellen.<\/p>\n\n\n\n Manuell geschriebene Dokumentationen werden schnell \u00fcberfl\u00fcssig und sind daher irref\u00fchrend und sch\u00e4digen den Entwickler-Workflow. Infolgedessen lesen die meisten Entwickler es nicht und vertrauen ihm auch nicht.<\/p>\n\n\n\n Manuelle API-Tests m\u00fcssen hunderte Male wiederholt werden<\/a>. Sie sind auch schwierig und zeitaufwendig (z.B. Einstellen und Verwalten von Daten in POSTman). In den meisten IT-Projekten ist es jedoch nach wie vor \u00fcblich, dies zu tun. Gl\u00fccklicherweise ist die Automatisierung beider Verfahren recht einfach zu realisieren.<\/p>\n\n\n\n Die meisten Entwickler sind vertraut mit REST-API-Tools zur Beschreibung und Dokumentation von REST-API-Endpunkten wie:<\/p>\n\n\n\n F\u00fcr einen Vergleich klicken Sie bitte hier<\/a>.<\/p>\n\n\n\n Beide enthalten viele n\u00fctzliche Tools und Integrationen:<\/p>\n\n\n\n Auch die Generierung des Swagger-Definitionsformats (das einen API-Endpunkt auf der Serverseite detailliert beschreibt) mit der Swagger-Oberfl\u00e4chenansicht aus dem Quellcode wird immer h\u00e4ufiger (z.B. Hapi.js mit Swagger-Plugin oder JAX-RS mit Annotationen).<\/p>\n\n\n\n Es garantiert aber immer noch nicht, dass die Dokumentation vollst\u00e4ndig mit dem Verhalten des Codes \u00fcbereinstimmt. In komplexen Systemen haben Sie weder die Kontrolle \u00fcber alle API-Endpunkte, noch k\u00f6nnen Sie diese \u00e4ndern oder automatisch Dokumente generieren lassen.<\/p>\n\n\n\n Wenn Sie Gl\u00fcck haben und alle Endpunkte vollst\u00e4ndig dokumentiert und mit Swagger oder RAML beschrieben sind, k\u00f6nnen Sie mit Hilfe von Tools mit geringem Aufwand automatisch eine API erstellen und ausf\u00fchren<\/strong>:<\/p>\n\n\n\n Es wird ein gro\u00dfer Vorteil f\u00fcr die t\u00e4gliche Entwicklung sein.<\/p>\n\n\n\n Aber zur\u00fcck zur Realit\u00e4t – das kann nur in kleinen Projekten passieren. Normalerweise haben Sie diesen Komfort nicht, und Sie m\u00fcssen selbst automatische API-Tests schreiben.<\/p>\n\n\n\nL\u00f6sung<\/h2>\n\n\n\n
Verwendung einer KonstruktionsrichtlinieIm <\/strong><\/h3>\n\n\n\n
Verwendung von automatisch generierter Dokumentation und Tests<\/strong><\/h3>\n\n\n\n
Tools verwenden<\/h2>\n\n\n\n
Schritt 1 – Automatische Generierung der Dokumentation<\/strong><\/h3>\n\n\n\n
Schritt 2 – Automatische API-Tests<\/strong><\/h3>\n\n\n\n