7 Tipps für die Erstellung besserer REST-APIs

Zu den häufigsten Fehlern, die Entwickler beim Erstellen einer REST-API machen, gehören:

• Schlecht geschriebene Dokumentation
• Undefinierte Architektur
• Inkonsistente Endpunktdefinitionen
• Unklare Kommunikation
• Schwache Sicherheitsmaßnahmen

Wir leben nicht in einer perfekten Welt. Es ist normal, Fehler zu machen. Bevor Sie sich jedoch an einem Projekt beteiligen, müssen Sie alle Vorsichtsmaßnahmen treffen und alle Risiken oder Fehler kennen, die Ihnen unterlaufen könnten.

Das Gleiche gilt auch für unseren Fall. Deshalb gibt dir unser Team in den folgenden Abschnitten einige Tipps, die auf den persönlichen und beruflichen Erfahrungen unserer Teammitglieder basieren.

Die Dokumentation Ihrer API hilft Ihnen und Ihrem Team, den Datenfluss der Anwendung besser zu verstehen. Beim Aufbau einer API treten unvermeidlich Probleme auf. Dinge wie Bibliotheksaktualisierungen, API-Versionierung oder Sicherheitsprobleme werden Sie wünschen lassen, Sie hätten die Dokumentation geschrieben.

Dadurch verringern Sie auch den Ressourcenaufwand für die Einarbeitung neuer Remote- oder interner Softwareentwickler und erleichtern dem Team die Durchführung von Updates und Wartungsmaßnahmen. Versuchen Sie, ihnen den Vorteil zu verschaffen, auf Ihrer API aufbauen zu können, auch ohne dass sie die von Ihnen verwendeten Technologien vollständig verstehen.

Glücklicherweise ist es heutzutage viel einfacher, Dokumentation zu erstellen. Tools wie Apiary, Swagger, Raml und viele andere helfen Entwicklern dabei, Dokumentation im Handumdrehen zu generieren. Sie können sich jederzeit von nützlicher, gut geschriebener Dokumentation wie The Rust Docs, GitHub Developer Docs, Ruby On Rails Guides, CasperJS oder Moment.js inspirieren lassen.

Wir sollten stets darauf achten, die Kommunikation zwischen Client und Server privat zu halten.

Entwickler nutzen APIs, um ihre Dienste aufzubauen und Daten zu übertragen. Wenn eine API fehlerhaft ist, offenliegt oder erhebliche Datenlecks aufweist, wird sie definitiv von keinem Entwickler ausgewählt werden.

Versuchen Sie, Anfrageparameter von Anfang an zu validieren. Implementieren Sie Validierungsprüfungen und blockieren Sie jede Anfrage, die diese spezifische Validierung nicht besteht. Fügen Sie Validierungen für Eingabetypen, Formate und Länge hinzu. Akzeptieren Sie nur bestimmte HTTP-Methoden für bestimmte Endpunkte und fügen Sie Zeitstempel für Ihre Anfragen hinzu, damit nur solche akzeptiert werden, die innerhalb eines bestimmten Zeitraums gestellt wurden. Dies verhindert einige der Brute-Force-Angriffe, die Ihre Server möglicherweise treffen könnten.

Sie können Ihre Authentifizierungssicherheit noch weiter verbessern, indem Sie das OAuth 2.0-Authentifizierungsframework implementieren. Mit Hilfe von Drittanbieter-Apps können Sie eine sicherere Umgebung für Ihre Nutzer schaffen.

Geben Sie niemals sensible Informationen wie Benutzernamen, Passwörter, API-Schlüssel usw. in URLs preis. Wenn Sie diese Informationen wirklich übertragen müssen, indem Sie sie in der URL speichern, serialisieren Sie sie so, dass nur der Rechner, mit dem Sie kommunizieren müssen, die empfangenen Daten versteht.

Die API ist wie eine Brücke zwischen dem Server und dem Client. Deshalb sollten wir Daten in einem Format übertragen, das für beide Seiten geeignet ist. Diese Wahl beeinflusst die Geschwindigkeit und den Erfolg der Anfragen.

Zu den am häufigsten verwendeten Datenformaten beim Aufbau einer API gehören Direktdaten, Feed-Daten und Datenbankdatenformate.

Direkte Datenformate sind die beste Option, wenn Sie mit anderen APIs interagieren möchten. Zu den am häufigsten verwendeten gehören JSON, YAML und XML.

Feed-Datenformate werden in der Regel verwendet, um Aktualisierungen von Servern oder Frontend-Webanwendungen zu veröffentlichen und Benutzer über diese Änderungen zu informieren. Wie Sie wahrscheinlich bereits erraten haben, werden diese Formate am häufigsten für soziale Medien, Blogs oder Videoplattformen verwendet.

In den meisten Fällen werden Datenbankdatenformate verwendet, um Daten zwischen verschiedenen Datenbanken oder zwischen anderen Anwendungen und Datenbanken zu bearbeiten. SQL und CSV sind zwei der am häufigsten verwendeten Formate in dieser Kategorie.

Wenn die API, die Sie und Ihr Team entwickeln, große Datenmengen zurückgibt, ist es möglicherweise sinnvoll, eine Paginierung zu implementieren. Wir sollten stets Situationen vermeiden, in denen der Nutzer die Möglichkeit hat, den Dienst zum Absturz zu bringen.

Wir empfehlen, ein Standardlimit für die zurückgegebenen Daten sowie Parameter wie „limit“ und „offset“ zu verwenden, etwa so: /users?limit=30&offset=60.

Die Paginierung bietet zudem eine hervorragende Möglichkeit, Ihren Nutzern bei der Entscheidungsüberlastung zu helfen, und beseitigt das ohnehin schon verhasste unendliche Scrollen.

Der Prozess der Versionierung einer API hilft Entwicklern, die Kontrolle über die Anwendung zu behalten. Man kann nie wissen, wie sich ein neues Update auf die Benutzerfreundlichkeit für jeden einzelnen Nutzer auswirkt. Versuchen Sie immer, die alten Versionen Ihrer API zu sichern, selbst wenn Sie sie komplett ändern.

Sehen wir uns einige Beispiele an, wie eine API versioniert werden kann:

• Fügen Sie die Versionsnummer direkt in die URL der API ein: api.example.com/v1/users
• Legen Sie benutzerdefinierte Header fest, um die Versionsnummer der API einzufügen: curl -H „API-version: 1.0“ https://api.example.com/users
• Passen Sie den Accept-Header so an, dass er die Versionsnummer der API enthält: curl -H „Accept: application/vnd.example.v1+json“ https://api.example.com/users
• Fügen Sie die Versionsnummer als Abfrageparameter hinzu: https://api.example.com/users?version=1

RESTful-APIs verfügen über vier Methoden, um anzugeben, was Entwickler mit den übergebenen Daten tun sollen.

Auch wenn es logisch erscheint, neigen Entwickler dazu, nur zwei der folgenden HTTP-Methoden zu verwenden. Es ist jedoch empfehlenswert, jede dieser Methoden einzusetzen, wann immer es die Situation erfordert.

• GET – Verwenden Sie diese Methode immer dann, wenn Sie eine Ressource oder eine Sammlung von Ressourcen abrufen müssen.
• POST – Entwickler sollten diese Methode immer dann verwenden, wenn sie eine neue Ressource oder eine Sammlung von Ressourcen erstellen müssen.
• PUT – Diese Methode wird zum Aktualisieren bestimmter Informationen verwendet.
• DELETE – Der Name ist selbsterklärend. Diese Methode hilft uns, vorhandene Ressourcen oder Sammlungen von Ressourcen zu löschen.

Genauso wie Entwickler es vorziehen, nur zwei der zuvor genannten HTTP-Codes zu verwenden, nutzen sie in den meisten Fällen auch tatsächlich nur zwei HTTP-Codes. Dies kann ihnen selbst in der Zukunft sowie allen Entwicklern, die später an dem Projekt arbeiten werden, viele Kopfschmerzen bereiten.

• 200 OK – Dies ist der häufigste Code, auf den wir als Entwickler stoßen. Oder zumindest hoffen wir das. Er wird uns angezeigt, wann immer ein Vorgang erfolgreich ausgeführt wurde.
• 201 CREATED – Die zuvor vorgestellte POST-Methode geht Hand in Hand mit diesem HTTP-Code, da er den Client darüber informieren soll, dass die Ressource erfolgreich erstellt wurde.
• 400 BAD REQUEST – Dies ist der HTTP-Code, der immer dann angezeigt wird, wenn eine Anfrage nicht erfolgreich ausgeführt wurde.
• 401 UNAUTHORIZED – Wenn wir den Zugriff eines Benutzers auf einen Teil unserer Anwendung einschränken müssen, sollte dies der HTTP-Code sein, den wir zusammen mit der Fehlermeldung senden.
• 404 NOT FOUND — Der häufigste HTTP-Code im gesamten Internet. Selbst Menschen, die sich nicht mit Softwareentwicklung auskennen, wissen, dass der HTTP-Code 404 bedeutet, dass die Ressourcen nicht gefunden wurden.
• 500 INTERNAL SERVER ERROR — Dieser Fehler sollte immer dann zurückgegeben werden, wenn der Server nicht reagiert.

Wie Sie sehen, sind alle HTTP-Codes ziemlich selbsterklärend. Wenn man jeden einzelnen von ihnen einsetzt, wenn es die Situation erfordert, kann das auf lange Sicht viel Zeit sparen.

Wir alle wissen, wie frustrierend es ist, wenn wir eine Fehlermeldung erhalten, die vage formuliert ist. Nicht nur funktioniert der Dienst nicht, sondern wir müssen nun auch noch herausfinden, woher das Problem stammt.

Wir müssen die richtigen Fehlermeldungen und den eindeutigsten HTTP-Fehlercode ausgeben, um diese Verwirrung zu beseitigen.

Wenn ein Nutzer beispielsweise ein neues Konto erstellen möchte, die E-Mail-Adresse auf der Plattform jedoch bereits vergeben ist, sollten wir einen HTTP-Code 400 mit der Meldung „E-Mail-Adresse bereits vorhanden“ zurückgeben. Auf diese Weise vermeiden wir eine beträchtliche Anzahl von Anfragen, da der Nutzer weiß, worin das Problem besteht, und die Registrierung nicht erzwingen wird.

Hier sind wir am Ende einer umfassenden Liste von Tipps angelangt. Dies sind nur einige der Methoden, mit denen Sie eine sicherere REST-API erstellen können. Natürlich gibt es noch viele weitere, aber wenn Sie nur die oben vorgestellten anwenden, sind Sie den meisten bereits bestehenden Lösungen wahrscheinlich schon einen Schritt voraus.

Wenn Sie jedoch nicht die Zeit und Geduld haben, eine API für Ihre Web-Scraping-Projekte zu entwickeln, warum investieren Sie dann nicht in eine fertige Lösung? Unser Team hat sich bemüht, eine der sichersten und benutzerfreundlichsten Web-Scraping-APIs zu entwickeln. Dies sind nur einige der wichtigsten Prinzipien, die dabei angewendet wurden, um sicherzustellen, dass es niemals zu Datenlecks oder API-Ausfällen kommt.

Wenn Sie es ausprobieren möchten, können Sie 1000 API-Aufrufe erhalten, indem Sie ein kostenloses Konto erstellen und eine der erfolgreichsten Web-Scraping-APIs testen.

Starten Sie jetzt Ihre Web-Scraping-Reise!