Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Carl Hanser Verlag GmbH & Co. KG
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Deutsch
- Veröffentlichungsjahr: 2019
RESTFUL GO APIS //
- Go und REST kompakt – alle wesentlichen Konstrukte der Programmiersprache Go und der Prinzipien von REST werden anschaulich und praxisnah erklärt.
- Lernen Sie anhand eines durchgängigen Beispiels, wie die Entwicklung von RESTAPIs in Go funktioniert.
- Erfahren Sie, wie die entwickelte API mit Hilfe hexagonaler Architekturprinzipien refaktorisiert und testbar gemacht wird.
- Lernen Sie, wie die entwickelte API zu einer Hypermedia API wird und damit zu einer »echten« REST API.
- Erlernen Sie die Grundlagen der Absicherung und Skalierung von APIs in Go und bereiten Sie API so für den Produktivbetrieb vor.
Alle bauen APIs. Grob geschätzt bestehen 80% der heute entwickelten Anwendungen im Kern aus einer oder mehreren serverseitigen Komponenten, die Geschäftslogik kapseln und diese ihren Clients über eine RESTful API zur Verfügung stellen. Ist das REST-Paradigma einmal verstanden, dann sind REST-APIs klar und einfach zu benutzen.
Go ist eine einfache, kompilierte und hoch performante Programmiersprache, die sich hervorragend für die Entwicklung von REST-APIs eignet. Eigenschaften, wie leichte Erlernbarkeit, ein simples und leistungsfähiges Concurrency-Modell, sehr guter HTTP-,REST- und JSON-Support, Cross-Plattform Fähigkeit, einfaches Deployment sowie hoch performante Binaries zeichnen Go aus.
Dieses Buch richtet sich an serverseitige Web-Entwickler und führt die wesentlichen Aspekte der REST-Entwicklung in Go anhand eines zunächst einfachen und im Verlauf des Buches komplexer werdenden Beispiels ein. Nach der Lektüre ist der Leser in der Lage, produktionsreife REST-APIs in Go zu entwickeln, zu deployen und zu betreiben.
Die Wahl des Namens “APIs” statt “Microservices” ist Absicht, um sich erstens vom gegenwärtigen Hype um Microservices abzusetzen und zweitens auch das große Feld monolithischer Anwendungen mit einzubeziehen.
Das Buch gliedert sich in drei Teile, von denen Teil 1 und 2 unverzichtbar sind. Teil 3 hat offenen Charakter und kann im Verlauf der Entstehung wachsen oder sich verkleinern.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 218
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Ralf Wirdemann
RESTful Go APIs
Design und Implementierungleichtgewichtiger Hypermedia Services
Der Autor:
Ralf Wirdemann, Hamburg,[email protected]
Alle in diesem Buch enthaltenen Informationen, Verfahren und Darstellungen wurden nach bestem Wissen zusammengestellt und mit Sorgfalt getestet. Dennoch sind Fehler nicht ganz auszuschließen. Aus diesem Grund sind die im vorliegenden Buch enthaltenen Informationen mit keiner Verpflichtung oder Garantie irgendeiner Art verbunden. Autor und Verlag übernehmen infolgedessen keine juristische Verantwortung und werden keine daraus folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieser Informationen – oder Teilen davon – entsteht. Ebenso übernehmen Autor und Verlag keine Gewähr dafür, dass beschriebene Verfahren usw. frei von Schutzrechten Dritter sind. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Buch berechtigt deshalb auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.
Bibliografische Information der Deutschen Nationalbibliothek:Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.
Dieses Werk ist urheberrechtlich geschützt.Alle Rechte, auch die der Übersetzung, des Nachdruckes und der Vervielfältigung des Buches, oder Teilen daraus, vorbehalten. Kein Teil des Werkes darf ohne schriftliche Genehmigung des Verlages in irgendeiner Form (Fotokopie, Mikrofilm oder ein anderes Verfahren) auch nicht für Zwecke der Unterrichtsgestaltung reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden.
© 2019 Carl Hanser Verlag München, www.hanser-fachbuch.deLektorat: Brigitte Bauer-SchiewekCopy editing: Jürgen Dubau, FreiburgLayout: le-tex publishing services GmbHUmschlagdesign: Marc Müller-Bremer, www.rebranding.de, MünchenUmschlagrealisation: Stephan Rönigk, unter Verwendung eines Bildmotivs von Astrid Ritscher
Print-ISBN: 978-3-446-45709-6E-Book-ISBN: 978-3-446-45978-6
Inhalt
Titelei
Impressum
Inhalt
1 Einleitung
1.1 Alle bauen APIs
1.2 Web-Frameworks
1.3 Alle wollen Go
1.4 Warum REST?
1.5 Aufbau des Buches
1.6 Disclaimer
1.7 Gebrauchsanleitung
1.8 Code-Beispiele
2 Go
2.1 Installation
2.2 Der Go-Workspace
2.3 Test der Installation
2.4 Programmstruktur
2.5 Packages
2.6 Funktionen
2.7 Variablen
2.8 Typen
2.9 Schleifen
2.10 Verzweigungen
2.11 Methoden
2.12 Pointer
2.13 Interfaces
2.14 Arrays und Slices
2.14.1 Arrays
2.14.2 Slices
2.14.3 Polymorphe Arrays
2.15 Maps
2.16 Verzögerungen, Panic und Recover
2.17 Was sonst noch?
3 REST
3.1 Überblick
3.2 Ressourcen
3.3 Uniform Ressource Identifier
3.4 HTTP-Methoden
3.4.1 GET
3.4.2 POST
3.4.3 PUT
3.4.4 DELETE
3.4.5 PATCH
3.4.6 HEAD
3.4.7 OPTIONS
3.5 Repräsentationen
3.6 Statuscodes
3.6.1 2xx Erfolg
3.6.2 3xx Umleitung
3.6.3 4xx Client-Fehler
3.6.4 5xx Server-Fehler
3.7 Hypermedia
3.8 REST als Architekturstil
3.8.1 Client-Server
3.8.2 Zustandslosigkeit
3.8.3 Cacheability
3.8.4 Uniform Interface
3.8.5 Layered System
3.8.6 Code on Demand
3.9 Zusammenfassung
4 HTTP und JSON
4.1 Das Package net/http
4.1.1 Request Handling
4.1.2 Level-2-Services
4.2 Das Package encoding/json
4.2.1 JSON-Encoding
4.2.2 JSON-Decoding
4.3 HTTP und JSON
4.4 Abschluss
5 Restvoice
5.1 Vision
5.2 Use Cases
5.3 Domainmodell
5.4 Ressourcen
5.5 Kern-Use-Cases
5.5.1 Rechnung erstellen
5.5.2 Buchung zufügen
5.5.3 Buchung löschen
5.5.4 Rechnung abschließen
5.5.5 Rechnung zustellen
5.6 Kritik am Entwurf
5.6.1 Sicherheit
5.6.2 Testbarkeit
5.6.3 Kopplung
5.6.4 RESTfulness
5.7 Warum Go?
5.8 Abschluss
6 Design
6.1 Layering
6.2 Domain-driven Design
6.3 Hexagonale Architektur
6.3.1 Beispiel
6.3.2 Der Use Case ELIZA
6.3.3 Ports und Adapter
6.4 Use Case „Rechnung erstellen“
6.4.1 HTTP ⇒ Invoice
6.4.2 Geschäftslogik
6.4.3 Invoice ⇒ HTTP
6.4.4 Bootstrapping
6.5 Use Case „Tätigkeit buchen“
6.6 Use Case „Rechnung abschließen“
6.7 Use Case „Rechnung anfordern“
6.8 Was haben wir erreicht?
6.8.1 Entkopplung
6.8.2 Wartbarkeit
6.8.3 Testbarkeit
7 Testing
7.1 Unit Tests
7.2 Unit Tests in Go
7.3 HTTP-Tests in Go
7.4 Was testen?
7.5 Beispiel: Rechnung abschließen
7.5.1 Testszenario
7.5.2 Method under Test
7.5.3 Unit Test
7.5.4 Integrationstest
7.6 Fake- und Mock-Objekte
7.6.1 Fake-Objekte
7.6.2 Mock-Objekte
7.7 Unit Test mit Fake-Objekt
7.8 HTTP-Test
7.9 API-Test
7.10 Testseparation
7.10.1 Build Tags: -tags
7.10.2 Short Modus: -short
7.10.3 Einzelne Tests ausführen: -run
7.11 Test Coverage
7.12 Abschluss
8 Hypermedia als Motor
8.1 HATEOAS
8.2 Hypermedia Rechnungsstellung
8.2.1 Zustandsübergänge
8.2.2 Wie sage ich es meinem Client?
8.3 Hypertext Application Language
8.4 HAL in Go
8.4.1 Geschäftslogik
8.4.2 Media Type „application/hal+json“
8.5 Hypermedia-Clients
8.6 Resource Expansion
8.7 CRUD vs. Hypermedia
8.8 Abschluss
9 Sicherheit
9.1 Client-Authentifizierung
9.1.1 HTTP Basic
9.1.2 HTTP Digest
9.1.3 JSON Web Token
9.2 Server-Authentifizierung
9.3 Autorisierung
9.4 Verschlüsselung
9.5 Abschluss
10 Skalierbarkeit
10.1 Horizontale Skalierung
10.2 Zustandslosigkeit
10.2.1 Sitzungsstatus
10.2.2 Clientstatus
10.2.3 Ressourcenstatus
10.3 Restvoice skalieren
10.4 Vertikale Skalierung
10.4.1 Go-Routinen
10.4.2 Restvoice vertikal skalieren
10.5 Abschluss
11 Caching
11.1 Arten von Caches
11.1.1 Lokaler Cache
11.1.2 Proxy Cache
11.1.3 Reverse Proxy Cache
11.2 HTTP Caching
11.2.1 GET
11.2.2 Cachebare Responses
11.2.3 Cache-Validierung
11.2.4 Cache-Invalidierung
11.3 Restvoice Caching
11.4 Activity Caching
11.4.1 Cacheable Responses
11.4.2 Cache-Validierung
11.4.3 Invalidierung
11.4.4 Alternative ETags
11.5 Abschluss
12 Wie geht es weiter?
12.1 Danke!
12.2 Feedback
Literatur
Ralf Wirdemann ist Programmierer und Pair-Programming-Coach. Neben technischer Exzellenz verfügt er über umfangreiches Prozess- und Methodenwissen.
Ralf Wirdemann begleitet Teams bei der Einführung neuer Technologien als Hands-On-Coach. Er versteht sich als Brücke zwischen Entwicklern und Projektmanagement. Agilität heißt für ihn, Verantwortung für das Ergebnis zu übernehmen.
Go ist eine einfache, statisch-getypte, compilierte und performante Programmiersprache, die sich hervorragend für die Entwicklung von REST-APIs eignet. Eigenschaften wie leichte Erlernbarkeit, ein simples und leistungsfähiges Concurrency-Modell, sehr guter HTTP-, REST- und JSON-Support, Cross-Plattform-Fähigkeit sowie das einfache Deployment zeichnen Go aus. REST ist ein Architekturstil für Hypermedia-Web-APIs. REST basiert auf HTTP und definiert eine Reihe von Constraints, deren Einhaltung eine API als RESTful qualifizieren.
Diese Buch führt Go und REST zusammen und beschreibt die Entwicklung Go-basierter REST-APIs. Die Idee zu diesem Buch hat sich über mehrere Jahre manifestiert und lässt sich auf drei wichtige Beobachtungen zurückführen: 1. Alle bauen APIs. 2. Alle benutzen Frameworks und richten ihre Anwendungsarchitektur daran aus. 3. Immer mehr APIs werden in Go programmiert.
Die meisten der heute entwickelten Softwaresysteme bestehen im Kern aus einer oder mehreren serverseitigen Komponenten, die Geschäftslogik kapseln und diese verschiedenen Clients über eine HTTP-API zur Verfügung stellen. Viele HTTP-APIs folgen dem REST-Architekturstil bzw. adaptieren Teile davon. Ist das REST-Paradigma einmal grundlegend verstanden, dann sind REST-APIs klar und einfach zu benutzen. Client und Server einigen sich auf eine Reihe standardisierter HTTP-Idiome und halten sich an diese Regeln.
Das Akronym API steht für Application Program Interface und beschreibt im ursprünglichen Sinne die Programmierschnittstelle einer Anwendung oder Bibliothek. APIs haben sich in den letzten Jahren von einem rein technischen Ansatz weg hin zu einem eigenständigen Geschäftsmodell entwickelt. Im Sinne von API-First ist die API heute Kern und nicht mehr nur ein reines Interface der Anwendung. Funktionierende Unternehmen öffnen sich über APIs und lassen neue Geschäftsmodelle entstehen. So erwirtschaften Expedia 90 %, eBay 60% und Salesforce 50% ihrer Gewinne allein über ihre APIs [ IS15].
Die zweite Beobachtung beschreibt den Umstand, dass viele Programmierer Frameworks für die Entwicklung von Web-APIs einsetzen. Die populärsten Vertreter sind Ruby on Rails, Spring MVC von Java oder das Django-Framework von Python. Web-Frameworks haben die Eigenschaft, dass sie dem Programmierer eine Architektur aufdrängen, die weniger an der Fachlichkeit als an den technischen Konzepten des Frameworks orientiert ist. Ein Beispiel sind Active-Record-Klassen in Rails, die Domainobjekte eng an die Datenbank koppeln.
Auf der anderen Seite finden die Ideen des Domain-driven Designs (DDD) zunehmend Beachtung [ Eva03]. DDD stellt die Fachlichkeit einer Anwendung in den Mittelpunkt des Designs und versucht, diese gut und stabil zu modellieren. Die Standardbibliothek von Go enthält Packages zur Programmierung von HTTP-basierten Web-APIs, die eher Library- als Framework-Charakter haben. Die HTTP-Programmierung in Go abstrahiert nur wenig und bleibt nahe am Protokoll. Die Nutzung setzt ein grundlegendes Verständnis von HTTP voraus, erlaubt aber auch das Bauen der technischen Konzepte um den eigentlichen Anwendungskern herum.
Die dritte Beobachtung fußt darauf, dass die Programmiersprache Go über die Jahre ihr Nischendasein verlassen hat. Waren es vor fünf Jahren noch ausschließlich sprachbegeisterte Programmierer, die sich mit Go beschäftigt haben, sind es im Juli 2018 bereits mehr als eine Million Go-Programmierer, von denen die meisten Web-APIs bauen [ The17].
Go wurde 2007 als Antwort auf die zunehmende Komplexität der Softwareentwicklung von Google ins Leben gerufen. Inzwischen wird Go neben Google von einer Reihe weiterer bekannter Firmen wie Netflix oder Dropbox eingesetzt. Go ist die Sprache der Cloud. Viele unternehmenskritische Systeme in der Cloud sind in Go geschrieben, zum Beispiel Kubernetes, Istio oder Docker.
Entwickler lieben Go besonders für die Cloud-Eigenschaften der Sprache: Einfachheit, Produktivität, Concurrency, geringe Latenz und geringer Speicherbedarf. Firmen beginnen, ihre existierenden Web-Services in Go neu zu entwickeln1. Im Vergleich zu Spring-Boot-basierten Web-Services belegt ein vergleichbarer Go-Service weniger als 10% des vom Java-Service benötigten RAM[ Hac18]. Bedenkt man, dass Amazon die Preise seiner EC2-Instanzen an CPU-Anzahl und RAM-Größe orientiert, dann wirkt die Umstellung auf Go mittelfristig kostensparend.
Diese drei Beobachtungen und Erkenntnisse haben mich veranlasst, dieses Buch zu schreiben. Das Buch führt die wesentlichen Aspekte der REST-Entwicklung in Go anhand eines einfachen Beispiels ein. Die Grundidee ist folgende: Nach einer knappen Einführung in Go und REST startet das Buch mit einer einfachen API, deren Entwurf anschließend analysiert und bewertet wird. Ausgehend von der Analyse wird die API um weitere Funktionalitäten erweitert und refaktorisiert. Dabei werden grundsätzliche Konzepte von APIs erklärt. Danach werden wir anhand eines realistischen Beispiels selbst eine API konstruieren und bis zur Produktionsreife verbessern.
REST ist eine von vielen Techniken, APIs zu bauen. Andere populäre Vertreter sind SOAP, JSON-RPC, gRPC oder GraphQL. Warum also ausgerechnet REST? Weil REST ein Architekturstil für WEB-APIs ist und nicht nur eine Technik, eine Bibliothek oder ein Framework. Ein Architekturstil geht über die Idee einer Programmierschnittstelle hinaus. Betrachtet man REST als reine Programmierschnittstelle, dann definiert diese lediglich den Aufruf von Anwendungsfunktionen über HTTP. Hingegen beschreibt der REST-Architekturstil Richtlinien und Prinzipien, wie die Anwendung zu strukturieren ist. Die Architektur steht im Zentrum und impliziert die Programmierschnittstelle.
Die derzeit wohl am meisten beachtete REST-Alternative ist GraphQL, das 2015 von Facebook entwickelt wurde [ Fac18]. GraphQL ist eine HTTP-basierte Query-Language, die JSON-basierte Queries gegen einen Endpunkt ermöglicht. GraphQL-Queries sind stark clientgetrieben, d. h. Clients können Anfragen exakt nach ihren jeweiligen Bedürfnissen formulieren. Dies ist insbesondere für APIs mit unterschiedlichen Clientanforderungen von Vorteil. So benötigen Smartphones andere Inhalte als Web-Browser. Anfragen können entsprechend seitenorientiert ausgelegt werden und in einer einzigen Antwort sämtliche von der jeweiligen Seite benötigten Informationen liefern.
REST hingegen ist clientagnostisch. Statt seitenorientierte Ergebnisse zu liefern, veröffentlicht eine REST-API Ressourcen, die über HTTP-Methoden erzeugt, angefordert, verändert und gelöscht werden. Angefangen vom Rechnungsdatensatz bis hin zu einem Geschäftsprozess kann eine Ressource alles sein, was als Konzept im Rahmen der API eine Rolle spielt.
REST-APIs veröffentlichen keine Anwendungsdetails, sondern Anwendungsfälle, wie zum Beispiel „Starte den Rechnungslauf für April 2018“. REST-Clients sind lose gekoppelt. Aufbau und Ablauf der Anwendungsfälle bleiben dem Client verborgen und können sich intern ändern, während die API nach außen stabil bleibt.
REST und GraphQL sind keine Konkurrenten, sondern Alternativen. Query-lastige APIs mit variablen Ergebnismengen legen den Einsatz von GraphQL nahe. Beispiele sind APIs mit vielen GET-Requests, deren Ergebnisse über Query-Parameter konfigurierbar sind. Geht es aber darum, die Geschäftsprozesse einer Anwendung über eine langlebige, stabile API zu veröffentlichen, dann ist REST der geeignete Kandidat.
Aber wie bereits eingangs erwähnt, ist REST ein Architekturstil, der aus einer Reihe von Prinzipien besteht, den sogenannten Constraints, die die Architektur der Anwendung maßgeblich bestimmen. Ziel dieser Prinzipien ist es, langlebige und skalierbare Web-Anwendungen zu bauen, die die Eigenschaften des HTTP-Protokolls wie URIs, Cacheability, Hyperlinks, Content Types, HTTP-Verben oder Statuscodes voll ausschöpfen. Insbesondere die Eigenschaft, ein Architekturstil zu sein, ist es, was REST von anderen API-Techniken unterscheidet und REST zu einem der wichtigsten Vertreter moderner API-Stile macht.
Der erste Teil dieses Buches schafft die Grundlagen und besteht aus den Kapiteln Go, REST und HTTP und JSON. Das Kapitel Go führt die syntaktischen Grundlagen von Go ein und beschränkt sich auf das Wesentliche. Weitere Go-Konstrukte und -Konzepte werden im Verlauf des Buches eingeführt, wenn sie benötigt werden. Kapitel 3 führt REST als praktisch anwendbaren Architekturstil ein, beschreibt den akademischen Hintergrund und nennt kurz die Schlüsselkonzepte der zugrunde liegenden Dissertation von Roy Thomas Fielding. Das Kapitel HTTP und JSON führt Go und REST zusammen und beschreibt das Handwerkszeug der HTTP-Programmierung in Go.
Der mittlere Teil des Buches besteht aus dem einzigen Kapitel 5. Restvoice ist der Name der diesem Buch zugrunde liegenden Beispiel-API, die in dem Kapitel als Minimal Viable Product (MVP) entwickelt wird. Ein MVP ist eine minimale Version des zu entwickelnden Systems, die ein einfaches Arbeiten ermöglicht.
Der dritte und größte Teil dieses Buches besteht aus sieben Kapiteln, die jedes einen Hauptaspekt der API-Entwicklung adressieren. Los geht es mit dem Kapitel Design, in dem die im Vorgängerkapitel entwickelte API überarbeitet und refaktorisiert wird. Grundidee des vorgeschlagenen Designs ist die strikte Trennung von Geschäftslogik und technischen Aspekten. Das Kapitel Testing setzt auf dem refaktorisierten Entwurf auf und beschreibt unterschiedliche Ansätze zum automatisierten Testen der API.
Die Kapitel Sicherheit, Skalierbarkeit und Caching beschreiben weniger REST-spezifische, als allgemeine Aspekte der serverseitigen Web-Entwicklung. Jede öffentliche API muss abgesichert sein. APIs müssen skalieren, insbesondere wenn sie erfolgreich sind. Das Kapitel Caching zielt in eine ähnliche Richtung: Je mehr Clients eine API hat, desto wichtiger ist die Minimierung von Latenzen und die Reduzierung der Zugriffe auf die eigentliche API durch das Vorschalten einer Caching-Infrastruktur.
Dieses Buch richtet sich an Programmierer. Sie sollten praktische Erfahrung in mindestens einer imperativen Programmiersprache wie Java, C, Python oder Ruby haben. Das Buch beginnt mit einer Einführung in Go. Das Kapitel ist kein Grundkurs in Programmierung, sondern konzentriert sich auf die syntaktischen und ideomatischen Aspekte von Go.
Sie haben ein Wochenende Zeit. Das sollte genügen, um dieses Buch zu lesen und die Beispiel-API nachzuprogrammieren. Montag wollen Sie mitreden können. Sie wollen Ihre Kollegen davon überzeugen, dass es eine gute Idee ist, die neue API in Go statt in Java zu entwickeln. Dann ist dieses Buch das richtige für Sie. Je nachdem, wo Sie stehen, bietet das Buch verschiedene Einstiegspunkte.
Sie sind versierter Programmierer, kennen Java, Python oder C, aber kein Go. Dann ist Kapitel 2Go Ihr Einstiegspunkt. Wenn Sie HTTP und REST gut kennen, dann können Sie Kapitel 3REST überspringen und direkt in das Kapitel HTTP und JSON wechseln und lernen, wie die HTTP-Programmierung in Go funktioniert.
Sie sind Go-Programmierer und wollen lernen, wie Sie eine REST-API bauen. Dann können Sie das Go-Kapitel überspringen und direkt mit Kapitel 3 in die Theorie von REST einsteigen. Oder wenn es sofort praktisch werden soll, dann ist Kapitel 4HTTP und JSON Ihr Startpunkt.
Sie sind Go-Programmierer, kennen sich mit HTTP aus und wissen, was REST ist. In diesem Fall ist das Kapitel 5Restvoice Ihr Einstiegspunkt. Das Kapitel enthält möglicherweise wenig Neues für Sie, ist aber Voraussetzung für das Verständnis der Folgekapitel Design, Testing und Hypermedia.
Dieses Buch enthält viel Sourcecode. Viele Beispiele sind aus dem Kontext herausgelöste Code-Fragmente, die einen bestimmten Aspekt der Go-Programmierung hervorheben sollen. Ich habe versucht, jedem Codebeispiel gerade soviel Kontext beizufügen, dass das Beispiel auf einen Blick und ohne weiteres Nachschlagen verständlich ist. Je nach Kenntnisstand des Lesers ist das ausreichend oder in einigen Fällen auch zu wenig Kontext. Deshalb finden Sie den kompletten Sourcecode der in diesem Buch entwickelten API in meinem öffentlichen GitHub-Repository: https://github.com/rwirdemann/restvoice.
1 zum Beispiel Volkswagen
