REST-API-Entwicklung

API, REST, WEB

Dieser Artikel enthält eine Reihe von Tools, die zum Erstellen einer REST-API erforderlich sind. Die Tools sind plattformunabhängig, d. h. sie sind auf REST-APIs anwendbar, die mit einem beliebigen Technologie-Stack erstellt wurden. Der Zweck dieses Artikels besteht darin, Anfänger-API-Entwickler in die verschiedenen Phasen der API-Entwicklung einzuführen und Tools vorzustellen, die in diesen Phasen hilfreich sind. Detaillierte Informationen zu diesen Tools finden Sie online. Die API-Entwicklungsschritte sind unten aufgeführt.

1. Design. Das Hauptziel hier ist es, die Form der API zu definieren, Schnittstellen zu dokumentieren und Endpunkte bereitzustellen.
2. Testen. In dieser Phase werden Funktionstests der API durchgeführt, indem eine Anfrage gesendet und die Antwort auf verschiedenen Sichtbarkeitsebenen analysiert wird, nämlich: Anwendung, HTTP, Netzwerk.
3. Webhosting. Bei Bereitstellung im Web gibt es HTTP-Tools, die beim Hosten von APIs helfen, Leistung, Sicherheit und Zuverlässigkeit zu verbessern.
4. Leistung Bevor wir uns an die Arbeit machen, verwenden wir Tools zum Testen der API-Leistung, um uns über die Last zu informieren, die die APIs unterstützen können.
5. Beobachtbar. Sobald die API in der Produktion bereitgestellt wurde, stellen Tests in der Produktion den Gesamtzustand der APIs sicher und warnen uns bei Problemen.
6. Management. Abschließend sehen wir uns einige API-Management-Tools wie Traffic Shaping, Deployment und so weiter an.

Die folgende Abbildung zeigt die verschiedenen Schritte und die verwendeten Werkzeuge.

Lassen Sie uns die Verwendung der von der Webanwendung bereitgestellten API-Tools bei der Entwicklung jeder Phase der API veranschaulichen. Produktkatalog
ist eine Spring Boot-Webanwendung, die einen Produktkatalog verwaltet. Es bietet eine REST-API zum Ausführen von CRUD-Vorgängen für einen Produktkatalog. Der Code ist [hier] verfügbar (https://github.com/Randhir123/product-catalog/).

Entwurf

Während der Entwurfsphase interagiert der API-Entwickler mit den API-Clients und dem Datenanbieter, um das API-Formular zu erhalten. Die REST-API besteht im Wesentlichen aus JSON-Messaging über HTTP. JSON ist das vorherrschende Format in REST-APIs, da es kompakt und leicht verständlich ist und ein flexibles Format hat, das keine Schemabeschreibung im Voraus erfordert. Darüber hinaus können verschiedene Clients dieselbe API verwenden und die Daten lesen, die sie benötigen.
Betrachten Sie ein API-Projekt mit Swagger. Dieses Tool verwendet ein offenes Format zur Beschreibung der API, kombiniert mit einer Webschnittstelle zur Visualisierung von Informationen über die Schnittstellen. Es gibt keine Trennung zwischen Design und Implementierung. Der Vorteil von Swagger besteht darin, dass die API und die Dokumentation ebenfalls synchron gehalten werden, wobei die Dokumentation neben der API gehostet wird. Der Nachteil ist, dass nur API-Entwickler die Struktur der API ändern können. Da die Dokumentation aus der API generiert wird, müssen wir zunächst ein Skelett unserer API erstellen. Wird von Spring Boot für die API-Entwicklung und das Springfox-Paket für die Dokumentationserstellung verwendet.
Fügen Sie swagger 2 und swagger-ui Maven-Abhängigkeiten zu Ihrer pom.xml hinzu.

<dependency>
    <groupId>io.springfox</groupId>
    <artifactId>springfox-swagger2</artifactId>
    <version>2.6.1</version>
</dependency>
<dependency>
    <groupId>io.springfox</groupId>
    <artifactId>springfox-swagger-ui</artifactId>
    <version>2.5.0</version>
</dependency>

Fügen Sie dem Projekt SwaggerConfig.java mit folgendem Inhalt hinzu:

package com.rks.catalog.configuration;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import springfox.documentation.builders.PathSelectors;
import springfox.documentation.builders.RequestHandlerSelectors;
import springfox.documentation.spi.DocumentationType;
import springfox.documentation.spring.web.plugins.Docket;
import springfox.documentation.swagger2.annotations.EnableSwagger2;
@Configuration
@EnableSwagger2
public class SwaggerConfig {
    @Bean
    public Docket api() {
        return new Docket(DocumentationType.SWAGGER_2)
        .select()
        .apis(RequestHandlerSelectors.any())
        .paths(PathSelectors.any()).build();
    }
}

Diese Konfiguration weist Swagger an, alle Controller zu crawlen und alle in diesen Controllern definierten URLs für die API-Dokumentation einzuschließen.
Nachdem Sie die Anwendung ausgeführt haben, können Sie die Swagger-API-Dokumentation unter folgender URL anzeigen:

http://localhost:8080/swagger-ui.html

Klicken Sie auf jede API, um Details anzuzeigen – URL, HTTP-Header und HTTP-Body. Nützlich ist die Schaltfläche „Probieren Sie es aus!“, die eine Sandbox bereitstellt, mit der Benutzer mit der API herumspielen können, um zu erfahren, wie sie funktioniert, bevor sie sie in ihre Anwendungen integrieren.

Testen

Funktionstests von REST-APIs beinhalten das Senden von HTTP-Anforderungen und das Validieren von Antworten, damit wir testen können, ob die APIs so funktionieren, wie wir es erwarten. REST verwendet HTTP als Transportmittel, das API-Anforderungs- und -Antwortformate definiert. TCP/IP wiederum empfängt HTTP-Nachrichten und entscheidet, wie sie über die Leitung gesendet werden. Einführung von drei Toolkits zum Testen von APIs auf drei Schichten des Protokollstapels, nämlich REST-Clients für die REST-Schicht, Web-Debugger für die HTTP-Schicht und Paket-Sniffer für die TCP/IP-Schicht.

• Postman ist ein REST-Client, mit dem wir die REST-API testen können. Dies ermöglicht uns:
• Erstellen Sie HTTP-Anforderungen und generieren Sie entsprechende cURL-Befehle, die in Skripten verwendet werden können.
• Erstellen Sie mehrere Umgebungen für Dev, Test, Pre-Prod, da jede Umgebung unterschiedliche Konfigurationen hat.
• Erstellen Sie eine Testsammlung, die mehrere Tests für jeden Bereich des Produkts enthält. Verschiedene Teile des Tests können parametrisiert werden, sodass wir zwischen den Umgebungen wechseln können.
• Erstellen Sie Codeschnipsel in JavaScript, um Tests zu erweitern. Zum Beispiel, um Rückgabecodes zu validieren oder Umgebungsvariablen festzulegen.
• Automatisieren Sie laufende Tests mit dem Newman-Befehlszeilentool.
• Testsammlungen und -umgebungen importieren / exportieren.

• cURL ist ein Befehlszeilentool, das einen eigenen HTTP-Stack verwendet und plattformübergreifend verfügbar ist.

curl -X POST \
  http://localhost:8080/books \
  -H 'Cache-Control: no-cache' \
  -H 'Content-Type: application/json' \
  -d '{
"id":"1",
"author":"shakespeare",
"title":"hamlet"
}'

• Burp ist ein HTTP-Debugger, mit dem wir den Webverkehr sehen können, der zwischen dem Client und der API geleitet wird. Es fungiert als Proxy zwischen dem Client und dem Server und ermöglicht es uns, die Anfrage und Antwort abzufangen und zu modifizieren, um Szenarien zu erstellen, die ansonsten schwer zu testen sind, ohne den Client zu modifizieren. Burp ist ein Toolkit, das hauptsächlich für Sicherheitstests verwendet wird, aber auch für API-Tests sehr nützlich sein kann. Richten Sie Ihren Postboten so ein, dass er die Anfrage an den Burp-Proxy sendet, und richten Sie Burp dann so ein, dass er die Anfrage des Clients und die Antwort des Servers abfängt.
  Fangen Sie die Anfrage und die Antwort wie unten gezeigt ab.

• Wireshark - Um einige API-Funktionen wie Verschlüsselung, Komprimierung usw. zu testen, müssen wir uns genauer ansehen, was im Netzwerk gesendet und empfangen wird. Wireshark ist ein Tool, das eine Netzwerkschnittstelle überwacht und eine Kopie aller TCP-Pakete aufbewahrt, die sie passieren. Der Datenverkehr wird in Schichten unterteilt - HTTP, TCP, IP usw. Es ist ein Assistent bei der Fehlerbehebung von Problemen, die eine eingehendere Untersuchung erfordern, wie z. B. TLS-Handshaking.

Web-Hosting

In diesem Abschnitt sehen wir uns einige der Funktionen des HTTP-Protokolls an, die bei richtiger Verwendung dazu beitragen, hochleistungsfähige, hochverfügbare, zuverlässige und sichere APIs bereitzustellen. Schauen wir uns insbesondere die drei Teile des HTTP-Protokolls an – Caching für Leistung, DNS für Hochverfügbarkeit und Skalierbarkeit und TLS für Transportsicherheit.

• Caching ist eine der besten Möglichkeiten, die Clientleistung zu verbessern und die API-Last zu reduzieren. HTTP ermöglicht es Clients, eine Kopie einer Ressource lokal zu speichern, indem als Antwort ein Caching-Header gesendet wird, sodass der Client beim nächsten Mal eine HTTP-Anforderung für dieselbe Ressource sendet, die aus dem lokalen Cache bereitgestellt wird. Dies spart Netzwerkverkehr und Rechenlast auf der API.
• HTTP 1.0 Expiration Caching bietet einen Expires-Header in einer HTTP-Antwort, der die Zeit angibt, zu der eine Ressource abläuft. Dies kann für eine gemeinsam genutzte Ressource mit einem festen Ablaufdatum nützlich sein.
• HTTP 1.1 Expiration Caching bietet eine flexiblere Ablauf-Header-Caching-Steuerung, die den Client anweist, die Ressource für den im max-age-Wert angegebenen Zeitraum zwischenzuspeichern. Es gibt einen weiteren s-maxage-Wert, der für Intermediäre festgelegt werden kann, z. B. einen Caching-Proxy.
• Zwischenspeichern der HTTP-Validierung. Es gibt ein Problem mit dem Caching, wenn ein Client eine veraltete Ressource hat oder zwei Clients unterschiedliche Versionen derselben Ressource haben. Wenn dies nicht akzeptabel ist oder wenn es personalisierte Ressourcen gibt, die nicht zwischengespeichert werden können, z. B. Authentifizierungstoken, bietet HTTP Validierungscaching. Stellt beim HTTP-Validierungs-Caching Header im Etag der Antwort oder den Zeitstempel der letzten Änderung bereit. Wenn die API einen der beiden Header zurückgibt, wird er von Clients zwischengespeichert und in nachfolgende GET-Aufrufe an die API aufgenommen.

GET http://api.endpoint.com/books
If-none-match: "4v44ffgg1e"

• DNS - Domain Name System findet IP-Adressen für einen Domainnamen, damit Clients ihre Anfrage an den richtigen Server weiterleiten können. Wenn eine HTTP-Anfrage gestellt wird, fragen Clients zuerst den DNS-Server ab, um die Hostadresse zu finden, und senden dann die Anfrage direkt an die IP-Adresse. DNS ist ein mehrschichtiges System, das stark zwischengespeichert wird, um sicherzustellen, dass Abfragen nicht verlangsamt werden. Clients unterhalten einen DNS-Cache, dann gibt es zwischengeschaltete DNS-Server, die zum Nameserver führen. DNS bietet CNAMEs (kanonische Namen) für den Zugriff auf verschiedene Teile eines Servers, zum Beispiel können eine API und ein Webserver auf demselben Server mit zwei verschiedenen CNAMEs gehostet werden – api.endpoint.com und www.endpoint.com – oder CNAMEs können verweisen auf verschiedene Server. CNAMEs ermöglichen es uns auch, Teile unserer API zu trennen. Für HTTP-GET-Anforderungen können wir einen separaten CNAME für statische und transaktionale Ressourcen haben, sodass wir einen externen Proxy für Ressourcen einrichten können, von denen wir wissen, dass sie zwischengespeichert werden könnten. Wir können auch einen CNAME für HTTP-POST-Anforderungen haben, um Lese- und Schreibvorgänge zu trennen, damit wir sie unabhängig skalieren können. Oder wir bieten Prioritätskunden eine Überholspur.

Wenn Sie erweitertes DNS wie Route53 verwenden, kann ein einzelner CNAME auf mehrere Server verweisen, anstatt nur auf einen Server zu verweisen. Die Routing-Richtlinie kann dann für gewichtetes Routing, verzögertes Routing oder Failover konfiguriert werden.

• TLS – Wir können unsere APIs mit TLS sichern, wodurch wir unsere Anfrage über HTTPS bedienen können. HTTPS arbeitet nach dem Grundprinzip der Schlüsselpaarsicherheit. Um HTTPS in unserer API zu aktivieren, benötigen wir ein Zertifikat auf unserem Server, das ein öffentliches/privates Schlüsselpaar enthält. Der Server sendet den öffentlichen Schlüssel an den Client, der ihn zum Verschlüsseln von Daten verwendet, und der Server verwendet seinen privaten Schlüssel zum Entschlüsseln. Wenn sich ein Client zum ersten Mal mit einem HTTPS-Endpunkt verbindet, findet ein „Handshake“ statt, d. h. Client und Server vereinbaren, wie der Datenverkehr verschlüsselt werden soll. Es wird ein Schlüssel ausgetauscht, der für die Sitzung eindeutig ist und zum Verschlüsseln und Entschlüsseln von Daten für die Dauer der Sitzung verwendet wird. Während des anfänglichen Handshakes gibt es aufgrund der asymmetrischen Verschlüsselung einen Leistungseinbruch, aber sobald die Verbindung hergestellt ist, wird die symmetrische Verschlüsselung verwendet, was ziemlich schnell ist.

Damit Proxys den TLS-Datenverkehr zwischenspeichern können, müssen wir dasselbe Zertifikat herunterladen, das zum Verschlüsseln des Datenverkehrs verwendet wird. Der Proxy muss in der Lage sein, den Datenverkehr zu entschlüsseln, in seinem Cache zu speichern, mit demselben Zertifikat zu verschlüsseln und an den Client zu senden. Einige Proxy-Server lassen dies nicht zu. In diesem Fall besteht die Lösung darin, zwei CNAMEs zu haben – einen für statisch zwischengespeicherte Ressourcen über HTTP und einen für nicht zwischengespeicherte personalisierte Ressourcen, deren Anforderungen über einen sicheren TLS-Kanal direkt von der API bedient werden.

Leistung

In diesem Abschnitt sehen wir uns Tools zum Testen unserer API an, um die Menge an Datenverkehr zu quantifizieren, die unsere Infrastruktur verarbeiten kann. Die Hauptidee des Leistungstests besteht darin, eine große Anzahl von Anfragen gleichzeitig an eine API zu senden und festzustellen, an welchem Punkt die Leistung abfällt und abstürzt.

Hier sind die Fragen, auf die wir Antworten brauchen:

• Welche Reaktionszeit kann die API unter verschiedenen Lastbedingungen bieten?
• Wie viele Anfragen gleichzeitig kann die API fehlerfrei verarbeiten?
• Welche Infrastruktur ist erforderlich, um die gewünschte Leistung zu erzielen?

loader.io ist ein kostenloser Cloud-basierter Lasttestdienst, mit dem wir unsere APIs einem Stresstest unterziehen können. Um die grundlegende Leistung der API zu erhalten, können Sie verschiedene Arten von Belastungstests mit steigenden Lasten ausführen, gemessen in Anfragen pro Sekunde, um Leistungsmetriken zu bestimmen, die durch Fehler und Antwortzeiten quantifiziert werden, für:

• Dauertest - durchschnittliche Belastung über lange Zeiträume, z. B. 48 Stunden bei 1 Anfrage pro Sekunde. Dadurch werden Speicherlecks oder andere ähnliche versteckte Fehler erkannt.
• Lasttest - Spitzenlast, z. B. Ausführen von 2.000 Anfragen pro Sekunde mit 6 API-Instanzen.
• Stresstest - Spitzenlast bei Überlast, z. B. 10 Minuten lang 10.000 Anfragen pro Sekunde ausführen.

Es ermöglicht uns auch, eine Infrastruktur zu definieren, die es uns ermöglicht, APIs mit der erforderlichen Leistung und linearen Skalierung unserer Lösung bereitzustellen.

Überwachungsfähigkeit

Die Bereitstellung einer API in der Produktion bedeutet nicht, dass wir die API vergessen können. Der Produktions-Rollout startet eine weitere Testphase, das In-Production-Testing, das Probleme aufdecken kann, die in früheren Phasen nicht entdeckt wurden. Das Testen im Produktionsprozess umfasst eine Reihe von Aktivitäten, die zu einem Ganzen kombiniert werden: Beobachtbarkeit (einschließlich Protokollierung), Überwachung, Verfolgung. Tools für diese Aktionen helfen bei der Diagnose und Lösung von Problemen in der Produktion.

• Protokollierung sollte explizit von Entwicklern durchgeführt werden, die ihre bevorzugte Protokollierungsumgebung und Protokollierungsstandard verwenden. Beispielsweise eine Protokollanweisung für alle 10 oder mehr Codezeilen, wenn der Code komplex ist und die Protokollebenen unterteilt sind in: 60 % DEBUG, 25 % INFO, 10 % WARN und 5 % ERROR.
• Überwachung - durchgeführt auf einer höheren Ebene als die Registrierung. Während die Protokollierung uns explizit mitteilt, was mit der API vor sich geht, stellt die Überwachung den Gesamtzustand der API sicher, indem gemeinsame Metriken verwendet werden, die von der Plattform und der API selbst bereitgestellt werden. Metriken werden normalerweise von einem Agent bereitgestellt, der auf einem Server bereitgestellt wird, oder sie können Teil einer Lösung sein und regelmäßig von einer remote bereitgestellten Überwachungslösung erfasst werden.

Die Lösung kann diagnostische Endpunkte enthalten, die den allgemeinen Status der API melden.

• Trace - Zipkin ist ein verteiltes Ablaufverfolgungssystem. Hilft bei der Erfassung der Timing-Daten, die zur Behebung von Latenzproblemen in Microservice-Architekturen erforderlich sind.

Das Aktivieren der zentralisierten Protokollierung umfasst Protokollierung und Ablaufverfolgung. Für die Überwachung können interessante Metriken in einem Zeitreihenspeicher wie Prometheus gespeichert und mit Grafana visualisiert werden.

Management

API-Verwaltungstools dienen als Gateway, das Dienste bereitstellt:

• API-Clients sichern sich ab, indem sie einen API-Schlüssel erhalten;
• API-Anbieter konfigurieren DNS, Caching, Drosselungsrichtlinien, API-Versionierung usw.

Diese und weitere Funktionen sind auf AWS API Gateway verfügbar.