Wirdemann RESTful Go APIs
1. Auflage 2019
ISBN: 978-3-446-45978-6
Verlag: Carl Hanser
Format: PDF
Kopierschutz: 1 - PDF Watermark
Design und Implementierung leichtgewichtiger Hypermedia Services
E-Book, Deutsch, 186 Seiten
ISBN: 978-3-446-45978-6
Verlag: Carl Hanser
Format: PDF
Kopierschutz: 1 - PDF Watermark
- 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.
Ralf Wirdemann ist erfahrener Software-Coach mit dem Schwerpunkt agile Softwareentwicklung. Er hat Scrum bereits in einer Reihe von Projekten eingeführt. Er ist Autor zahlreicher Fachartikel und gefragter Sprecher auf Konferenzen.
Autoren/Hrsg.
Fachgebiete
Weitere Infos & Material
1;Inhalt;6
2;1 Einleitung;14
2.1;1.1 Alle bauen APIs;14
2.2;1.2 Web-Frameworks;15
2.3;1.3 Alle wollen Go;15
2.4;1.4 Warum REST?;16
2.5;1.5 Aufbau des Buches;17
2.6;1.6 Disclaimer;17
2.7;1.7 Gebrauchsanleitung;18
2.8;1.8 Code-Beispiele;18
3;2 Go;20
3.1;2.1 Installation;20
3.2;2.2 Der Go-Workspace;21
3.3;2.3 Test der Installation;22
3.4;2.4 Programmstruktur;22
3.5;2.5 Packages;23
3.6;2.6 Funktionen;24
3.7;2.7 Variablen;24
3.8;2.8 Typen;25
3.9;2.9 Schleifen;27
3.10;2.10 Verzweigungen;28
3.11;2.11 Methoden;30
3.12;2.12 Pointer;31
3.13;2.13 Interfaces;32
3.14;2.14 Arrays und Slices;34
3.14.1;2.14.1 Arrays;34
3.14.2;2.14.2 Slices;34
3.14.3;2.14.3 Polymorphe Arrays;36
3.15;2.15 Maps;36
3.16;2.16 Verzögerungen, Panic und Recover;37
3.17;2.17 Was sonst noch?;39
4;3 REST;40
4.1;3.1 Überblick;40
4.2;3.2 Ressourcen;42
4.3;3.3 Uniform Ressource Identifier;42
4.4;3.4 HTTP-Methoden;43
4.4.1;3.4.1 GET;43
4.4.2;3.4.2 POST;44
4.4.3;3.4.3 PUT;44
4.4.4;3.4.4 DELETE;44
4.4.5;3.4.5 PATCH;44
4.4.6;3.4.6 HEAD;44
4.4.7;3.4.7 OPTIONS;44
4.5;3.5 Repräsentationen;45
4.6;3.6 Statuscodes;45
4.6.1;3.6.1 2xx Erfolg;46
4.6.2;3.6.2 3xx Umleitung;46
4.6.3;3.6.3 4xx Client-Fehler;46
4.6.4;3.6.4 5xx Server-Fehler;46
4.7;3.7 Hypermedia;47
4.8;3.8 REST als Architekturstil;48
4.8.1;3.8.1 Client-Server;48
4.8.2;3.8.2 Zustandslosigkeit;48
4.8.3;3.8.3 Cacheability;49
4.8.4;3.8.4 Uniform Interface;49
4.8.5;3.8.5 Layered System;49
4.8.6;3.8.6 Code on Demand;50
4.9;3.9 Zusammenfassung;50
5;4 HTTP und JSON;52
5.1;4.1 Das Package net/http;52
5.1.1;4.1.1 Request Handling;52
5.1.2;4.1.2 Level-2-Services;56
5.2;4.2 Das Package encoding/json;58
5.2.1;4.2.1 JSON-Encoding;59
5.2.2;4.2.2 JSON-Decoding;61
5.3;4.3 HTTP und JSON;62
5.4;4.4 Abschluss;63
6;5 Restvoice;64
6.1;5.1 Vision;64
6.2;5.2 Use Cases;65
6.3;5.3 Domainmodell;66
6.4;5.4 Ressourcen;68
6.5;5.5 Kern-Use-Cases;68
6.5.1;5.5.1 Rechnung erstellen;70
6.5.2;5.5.2 Buchung zufügen;73
6.5.3;5.5.3 Buchung löschen;76
6.5.4;5.5.4 Rechnung abschließen;77
6.5.5;5.5.5 Rechnung zustellen;78
6.6;5.6 Kritik am Entwurf;79
6.6.1;5.6.1 Sicherheit;79
6.6.2;5.6.2 Testbarkeit;80
6.6.3;5.6.3 Kopplung;80
6.6.4;5.6.4 RESTfulness;81
6.7;5.7 Warum Go?;81
6.8;5.8 Abschluss;82
7;6 Design;84
7.1;6.1 Layering;85
7.2;6.2 Domain-driven Design;85
7.3;6.3 Hexagonale Architektur;86
7.3.1;6.3.1 Beispiel;88
7.3.2;6.3.2 Der Use Case ELIZA;88
7.3.3;6.3.3 Ports und Adapter;89
7.4;6.4 Use Case „Rechnung erstellen“;90
7.4.1;6.4.1 HTTP Invoice;91
7.4.2;6.4.2 Geschäftslogik;92
7.4.3;6.4.3 Invoice HTTP;93
7.4.4;6.4.4 Bootstrapping;93
7.5;6.5 Use Case „Tätigkeit buchen“;95
7.6;6.6 Use Case „Rechnung abschließen“;96
7.7;6.7 Use Case „Rechnung anfordern“;98
7.8;6.8 Was haben wir erreicht?;99
7.8.1;6.8.1 Entkopplung;100
7.8.2;6.8.2 Wartbarkeit;100
7.8.3;6.8.3 Testbarkeit;101
8;7 Testing;102
8.1;7.1 Unit Tests;102
8.2;7.2 Unit Tests in Go;103
8.3;7.3 HTTP-Tests in Go;105
8.4;7.4 Was testen?;106
8.5;7.5 Beispiel: Rechnung abschließen;107
8.5.1;7.5.1 Testszenario;108
8.5.2;7.5.2 Method under Test;108
8.5.3;7.5.3 Unit Test;110
8.5.4;7.5.4 Integrationstest;110
8.6;7.6 Fake- und Mock-Objekte;112
8.6.1;7.6.1 Fake-Objekte;112
8.6.2;7.6.2 Mock-Objekte;114
8.7;7.7 Unit Test mit Fake-Objekt;115
8.8;7.8 HTTP-Test;115
8.9;7.9 API-Test;116
8.10;7.10 Testseparation;118
8.10.1;7.10.1 Build Tags: -tags;118
8.10.2;7.10.2 Short Modus: -short;119
8.10.3;7.10.3 Einzelne Tests ausführen: -run;119
8.11;7.11 Test Coverage;119
8.12;7.12 Abschluss;121
9;8 Hypermedia als Motor;122
9.1;8.1 HATEOAS;123
9.2;8.2 Hypermedia Rechnungsstellung;123
9.2.1;8.2.1 Zustandsübergänge;124
9.2.2;8.2.2 Wie sage ich es meinem Client?;125
9.3;8.3 Hypertext Application Language;126
9.4;8.4 HAL in Go;129
9.4.1;8.4.1 Geschäftslogik;129
9.4.2;8.4.2 Media Type „application/hal+json“;130
9.5;8.5 Hypermedia-Clients;132
9.6;8.6 Resource Expansion;134
9.7;8.7 CRUD vs. Hypermedia;137
9.8;8.8 Abschluss;138
10;9 Sicherheit;140
10.1;9.1 Client-Authentifizierung;140
10.1.1;9.1.1 HTTP Basic;141
10.1.2;9.1.2 HTTP Digest;145
10.1.3;9.1.3 JSON Web Token;147
10.2;9.2 Server-Authentifizierung;152
10.3;9.3 Autorisierung;154
10.4;9.4 Verschlüsselung;156
10.5;9.5 Abschluss;157
11;10 Skalierbarkeit;160
11.1;10.1 Horizontale Skalierung;160
11.2;10.2 Zustandslosigkeit;161
11.2.1;10.2.1 Sitzungsstatus;161
11.2.2;10.2.2 Clientstatus;161
11.2.3;10.2.3 Ressourcenstatus;162
11.3;10.3 Restvoice skalieren;163
11.4;10.4 Vertikale Skalierung;163
11.4.1;10.4.1 Go-Routinen;164
11.4.2;10.4.2 Restvoice vertikal skalieren;164
11.5;10.5 Abschluss;166
12;11 Caching;168
12.1;11.1 Arten von Caches;168
12.1.1;11.1.1 Lokaler Cache;168
12.1.2;11.1.2 Proxy Cache;169
12.1.3;11.1.3 Reverse Proxy Cache;169
12.2;11.2 HTTP Caching;169
12.2.1;11.2.1 GET;169
12.2.2;11.2.2 Cachebare Responses;169
12.2.3;11.2.3 Cache-Validierung;170
12.2.4;11.2.4 Cache-Invalidierung;172
12.3;11.3 Restvoice Caching;172
12.4;11.4 Activity Caching;172
12.4.1;11.4.1 Cacheable Responses;172
12.4.2;11.4.2 Cache-Validierung;174
12.4.3;11.4.3 Invalidierung;176
12.4.4;11.4.4 Alternative ETags;177
12.5;11.5 Abschluss;177
13;12 Wie geht es weiter?;178
13.1;12.1 Danke!;178
13.2;12.2 Feedback;179
14;Literatur;180
15;Stichwortverzeichnis;182
| 2 | Go |
Go ist eine schlanke Programmiersprache und kommt mit 25 Keywords aus. Go ist weder ausdrücklich funktional noch ausdrücklich objektorientiert. Dennoch lassen sich beide Paradigmen in Go umsetzen. Dieses Kapitel führt in die Grundlagen der Programmiersprache Go ein.
Das Kapitel beginnt mit der Installation einer Go-Entwicklungsumgebung und der Beschreibung des Go-Workspace. Anschließend werden die Basiskonstrukte von Go beschrieben: Packages strukturieren Go-Dateien auf oberster Ebene und definieren die Sichtbarkeit enthaltener Elemente. Funktionen implementieren Programmlogik mithilfe von Schleifen, Bedingungen und Variablen. Typen stehen entweder in Form von Standard- oder benutzerdefinierten Typen zur Verfügung.
Nach Einführung dieser grundlegenden und aus anderen Programmiersprachen bekannten Sprachkonstrukte fährt das Kapitel mit den Besonderheiten von Go fort: Pointer, Interfaces und Methoden. Pointer ermöglichen die explizite Unterscheidung von Werte- und Referenztypen. Interfaces trennen Schnittstelle und Implementierung von Typen. Methoden implementieren Funktionen auf benutzerdefinierten Typen, die auf Instanzen des jeweiligen Typs gebunden werden.
Im letzten Abschnitt werden mit Arrays und Maps zwei der neben den Standardtypen wichtigsten Go-Typen beschrieben. Arrays implementieren typisierte Listen fester Länge. Maps dienen der Verwaltung typisierter Key-/Value-Paare.
| 2.1 | Installation |
Go-Distributionen stehen zum Binär-Download für MacOS, Windows und Linux unter bereit. Unter MacOS wird die Go-Distribution nach installiert. Damit die Go-Tools im Terminal funktionieren, muss die PATH-Variable um den Pfad erweitert werden. Führen Sie das Go-Tool in einem neuen Terminalfenster mit dem Parameter aus:
Entspricht die Ausgabe dem Beispiel, dann hat alles funktioniert, und die Go-Entwicklungsumgebung steht bereit. Weitere Installationshinweise sowie Anleitungen für die Go-Installation unter Windows und Linux finden Sie hier .
| 2.2 | Der Go-Workspace |
Das grundlegende Konzept einer Go-Entwicklungsumgebung ist der . Der Go-Workspace ist ein zentrales Verzeichnis, das über die Umgebungsvariable referenziert wird. Unterhalb des GOPATH finden sich die drei Unterverzeichnisse , und :
Go-Programmewerden compiliert und zu einem statischen Binary gelinkt. Die resultierende Binärdatei landet im Verzeichnis des Go-Workspace. Zusammengehörige Dateien, sogenannte , werden zu einer -Datei übersetzt und in eines der plattformspezifischen Unterverzeichnisse von abgelegt. Das Unterverzeichnis enthält die Dateien mit den Go-Sourcen, geordnet in Unterverzeichnisse, die die Package-Struktur widerspiegeln.
Die zugrunde liegende Idee des Go-Workspace ist, dass alle Projekte inklusive der benötigten Abhängigkeiten an zentraler Stelle abgelegt werden. Projekte werden schnell gefunden und können sich benötigte Bibliotheken teilen. Die Nutzung mehrerer Workspaces ist durch die Verwendung der Umgebungsvariable GOPATH einfach möglich.
Der Go-Workspace ist prinzipiell eine gute Idee, birgt aber auch eine Reihe praktischer Probleme. So ist es nicht ohne Weiteres möglich, unterschiedliche Versionen eines Packages im selben Workspace zu verwalten. Es ist auch nicht möglich, eine Bibliothek zu veröffentlichen, die eine bestimmte Version einer abhängigen Bibliothek benötigt.
Mit Version 1.5 wurde Go um eine Dependency-Management-Technik, das sogenannte erweitert. Mit Vendoring kann man einem Projekt weitere Abhängigkeiten aus einem projektlokalen vendor-Verzeichnis zufügen. Seit Go-Version 1.11 steht mit eine Ablösung des Vendoring ins Haus. Die Beispiele in diesem Buch funktionieren GOPATH-basiert. Die Beschäftigung mit Vendoring oder besser ist an dieser Stelle nicht erforderlich. Spätestens wenn es in die Praxis geht, müssen Sie sich mit dem Thema Dependency Management beschäftigen. Das Go-Wiki enthält eine gute Einführung zur Funktionsweise und Benutzung von Go Modules [ The18].
| 2.3 | Test der Installation |
Erstellen Sie den Go-Workspace mit den drei Unterverzeichnissen , und und exportieren Sie dessen Verzeichnis in der Umgebungsvariable GOPATH:
Anschließend wird im Verzeichnis eine Datei mit folgendem Inhalt erstellt:
Die Funktion im Package ist der Einstiegspunkt in ein Go-Programm und wird beim Start des Programms ausgeführt. Das Kommando compiliert und führt das Programm aus:
Das Kommandozeilentool ist das zentrale Werkzeug einer Go-Distribution. Entsprechend parametrisiert lassen sich damit alle wichtigen Entwicklungsaufgaben ausführen. Einige Beispiele:
Ein vollständige Dokumentation der Go-Tools finden Sie unter .
| 2.4 | Programmstruktur |
Go-Quellcode ist auf Dateien mit dem Suffix verteilt. Die Struktur einer Go-Datei wird auf oberster Ebene durch sechs Keywords bestimmt:
Das erste Statement einer Go-Datei ist immer , gefolgt von einem oder mehreren -Statements zum Import referenzierter Packages. Anschließend folgen Variablen- und Konstantendeklarationen sowie Typ- und Funktionsdefinitionen in beliebiger Reihenfolge und Anzahl.
| 2.5 | Packages |
Go-Files werden in Packages organisiert. Alle Dateien eines Verzeichnisses gehören zum selben Package. Der letzte Teil des Pfadnamens bestimmt den Package-Namen. Gemäß dieser Konvention liegt die Datei im Verzeichnis und gehört zum Package :
Packages definieren Namensräume. Die Sichtbarkeit von Typen, Funktionen, Variablen und Konstanten wird mithilfe von Groß- und Kleinschreibung definiert. Alles Kleingeschriebene ist ausschließlich innerhalb des Packages sichtbar. Alles Großgeschriebene ist auch außerhalb des Packages sichtbar. Packages werden über das -Statement importiert. Öffentliche Typen, Variablen und Funktionen werden genutzt, indem der Package-Name dem importierten Element vorangestellt wird:
Die Funktion importiert das Package und ruft die exportierte Funktion auf. Das main-Beispiel zeigt eine Ausnahme in Bezug auf die Namenskonvention für Packages: Die Go-Datei mit der Funktion gehört zum Package main, unabhängig vom Verzeichnis, in dem sie liegt.
Initialisierung
Jede Datei eines Packages kann eine -Funktion enthalten, in der paketweite Initialisierungsaufgaben ausgeführt werden. Init-Funktionen werden beim Laden eines Packages automatisch ausgeführt:
Init-Funktionen sind Package-intern und können aus keinem anderen Package heraus aufgerufen werden. Ein anonymer Package-Import sorgt für die Ausführung von , ohne dass eine öffentliche Funktion des importierten Packages aufgerufen werden muss. Dies ist zum Beispiel dann sinnvoll, wenn eine Bibliothek Initialisierungscode enthält, der nie explizit aufgerufen wird, für das Funktionieren des Programmes aber einmalig ausgeführt werden muss. Das Laden eines Datenbanktreibers ist ein Beispiel:
Der Import...
