How to build a REST API

Alle komplexen Programme verwenden Schnittstellen (eine API), um miteinander zu kommunizieren – aber wie funktioniert das und ist es möglich, eine solche selber erfahrungslos zu programmieren?

Was ist eine REST API?
API (Application Programming Interface) ist eine Programierschnittstelle, welche Soft- und Hardwarekomponenten, beispielsweise Anwendungen, Festplatten oder Benutzeroberflächen, miteinander verbindet. Mit REST ist aber nicht etwa Ausruhen gemeint, sondern Representational State Transfer. Dies bezeichnet die Art, wie verteilte Systeme miteinander kommunizieren können. Bahnhof verstanden?

Deshalb eine einfache Visualisierung dazu:

Die API ist also eine spezifische Schnittstelle, über welche die Entwickler vorgefertigte Blöcke und Funktionen zur Erstellung ihres Softwareprodukts verwenden können.
Mit anderen Worten: API in der Programmierung ist ein vorgefertigter Code, der dem Programmierer die Entwicklung einer Anwendung vereinfacht. Mit seiner Hilfe wird die Erstellung eines neuen Produktes stark vereinfacht. Im Beispiel einer Restaurantbestellung würde die API die Stelle des/der Serviceangestellten übernehmen.

Der als REST (oder auch ReST) bezeichnete Architekturansatz beschreibt dabei, wie verteilte Systeme miteinander kommunizieren können. REST ist eine einfache Möglichkeit, Daten zwischen Client und Server zu senden und zu empfangen, wobei nur wenige Standards definiert sind. Es ist dabei möglich die Daten als JSON, XML oder als Plain-Text zu senden und zu empfangen. Alternativen zu einer REST API sind z.B. SOAP oder WSDL.

Was ist Node.JS?
Natürlich muss diese API irgendwo programmiert werden. Dazu habe ich die Open Source-Serverumgebung Node.js verwendet. Die Laufzeitumgebung läuft dabei auf diversen Betriebssystemen und verwendet JavaScript auf dem Server.

Node.js wird dabei oft mit PHP verglichen und wurde bereits als potentieller Nachfolger davon gehandelt. Der grosse Vorteil gegenüber PHP ist, dass es asynchron läuft und nicht jede Anfrage nacheinander abarbeitet, sondern dies zeitgleich macht. Es eliminiert daher das Warten und fährt einfach mit der nächsten Anfrage fort. Des Weiteren ist es «leichtgewichtig» gebaut und sehr effizient in der Datenverarbeitung.

runningMate Web-App
Für die Umsetzung hatte ich die Idee, eine Web-App für Einsteiger bis ambitionierte Läufer zu programmieren, welche es ermöglicht, sich im näheren Umkreis zu finden und ein gemeinsames Training zu vereinbaren.

Die von mir umgesetzte und ausschliesslich für mobile Endgeräte verfügbare Web-App findest du hier. Den Source-Code für die Web-Applikation sowie die API habe ich auf GitHub veröffentlicht.

(sba)

Kritik
von Sandro Anderes

Für mein Digezz-Projekt bin ich nach der IPERKA-Methode vorgegangen und möchte mit diesem auch die Kritik verfassen:

Informationen beschaffen

Ich wollte mich mit der Thematik Node.js und API näher auseinandersetzen und habe mir Gedanken gemacht wie ich dies am Besten umsetzen könnte. Da ich als ambitionierter Sportler immer wieder auf das Problem stosse alleine trainieren zu müssen, kam mir während einer Trainingseinheit die Idee eine App zu entwicklen, bei welcher man sich zu Trainings verabreden kann.

Konkrete Projektidee:
- App zum Treffen von gleichgesinnten Läufern im nähren Umkreis mithilfe von Webtechnologien wie Node.js und PHP
- Umsetzung mit einer API

Zielgruppe:
- Einsteiger und ambitioniert Läufer

Wie muss es sein:
- Einfach und für jeden verständlich, ansprechend und modern

Deadline:
- Publikationstermin Digezz (7. Januar)

Planen

Damit das Projekt reibungsfrei abläuft mussten in der Planung einige Schritte beachtet werden. Als erstes musste ich mich in die diversen Thematiken und Technologien einlesen und mir ein konkretes Produkt vorstellen. Als weiteren Schritt habe ich die einzelnen Teilaufgaben sowie die Meilensteine definiert. Als letztes haben ich die einzelnen Tasks priorisiert und Reservezeit für Unerwartetes eingeplant.

Meilensteine:
- Bis 21. September: Konkrete Projektidee definieren
- 23. September: Definitiver Projektstart
- 31. Oktober: Fertigstellung API
- 30. November: Fertigstellung Web-App
- 8. Dezember: Überarbeitung und Anpassungen
- 27. Dezember: Publikationsbericht und Kritik und letzte Änderungen
- 7. Dezember: Publikationstermin

Entscheiden

Beim Einarbeiten in die Thematik habe ich gemerkt, dass der Aufwand für eine native App also spezifisch für iOS oder Android aufgrund keiner Vorkenntnisse die Grenzen deutlich sprengen würden. Ich habe daher entschieden, eine Web-Applikation zu realisieren, welche auf allen mobilen Endgeräten läuft. Weiter habe ich die Funktionen dieser App definiert und eine grobe Struktur erstellt. Da das Projekt allerdings als Einzelarbeit und für eigene Learnings umgesetzt wird, mussten keine weiteren Entscheidungen gefällt werden.

Realisieren

Der Hauptteil war natürlich die Umsetzung des Projektes. Wie geplant habe ich zuerst die API und anschliessend die Web-App realisiert. Die grosse Schwierigkeit war dabei, dass die Anfragen und Antworten zwischen der App und der Node.js API funktionierten. Zu Beginn hatte ich Schwierigkeiten, dass die Requests korrekt verarbeitet und die JSON-Daten übergeben werden, da die Zertifizierung zwischen den beiden Anwendungen falsch eingestellt bzw. nicht vorhanden war. Dies konnte ich durch die Konfigurierung der Cross-Origin Resource Sharing (CORS) im Node.js-Script anpassen und zusammen mit der Applikation "Postman" testen. Dennoch gab es Zertifizierungs-Probleme. Diesmal weil die Web-App mit HTTPS läuft, meine API jedoch nur HTTP unterstütz. Auf der mir verfügbaren Linux-Umgebung auf welcher Node.js läuft, war es mir dann möglich über die Konsole mithilfe von "Let's Encrypt" das HTTPS-Protokoll zu installieren und die Verbindung zwischen den beiden Anwendungen zu ermöglichen.

Eine weitere Hürde war die Implementierung der Funktion, dass die aktuelle Position ausgelesen und verglichen werden kann. Mein Ziel war es die Distanz zwischen meiner aktuellen Position und der, aller Anderen (mit Berücksichtigung der Krümmung der Erdkugel) korrekt darzustellen.

Mir gelang beides relativ gut, allerdings musste ich dazu deutlich mehr Zeit als geplant investieren.

Kontrollieren

Damit bei der Abgabe keine Überraschungen auftreten, habe ich mich an folgende Vorgaben gehalten:
- Meilensteine überprüfen
- Vergleich von Planung und Umsetzung
- Eigen und Fremdkontrolle
- Qualitätskontrolle

Auswerten

Als letzten Teilschritt habe ich ein Fazit über die einzelnen Teilprojekte sowie über das Gesamtprojekt gezogen und reflektiert, was ich in Zukunft besser machen kann.

Ich kann sagen, dass ich alle Ziele wie geplant erreicht habe und die Ressourcen, vor allem auch das Zeitmanagement optimal einsetzen konnte. Für zukünftige Projekte würde ich erneut nach der IPERKA-Methode vorgehen. Einzig bei der Einschätzung der Arbeitsstunden bin ich etwas von meinen Erwartungen abgewichen und haben den Aufwand deutlich unterschätzt.

Dazu ist zu sagen, dass ich durch die Umsetzung dieses Projektes in den Bereichen Node.js, API, Web-Development sowie GitHub enorm viel dazu gelernt habe und auch in Zukunft wieder auf das erlernte zurückgreifen kann.

Keine Kommentare

Schreibe einen Kommentar