RESTful Go APIs

Name: RESTful Go APIs | Design und Implementierung leichtgewichtiger Hypermedia Services
Brand: Hanser
Price: 34.99 EUR
Availability: OnlineOnly

Design und Implementierung leichtgewichtiger Hypermedia Services

Ralf Wirdemann(Autor*in)

Hanser (Verlag)

1. Auflage

Erschienen am 11. März 2019

186 Seiten

E-Book

ePUB mit Wasserzeichen-DRM

Systemvoraussetzungen

E-Book

PDF mit Wasserzeichen-DRM

Systemvoraussetzungen

978-3-446-45978-6 (ISBN)

34,99 €inkl. 7% MwSt.

Systemvoraussetzungen

für ePUB mit Wasserzeichen-DRM und PDF mit Wasserzeichen-DRM

(Hinweis: Die Auswahl des von Ihnen gewünschten Dateiformats und des Kopierschutzes erfolgt erst im System des E-Book Anbieters)

E-Book Einzellizenz

Als Download verfügbar

Beschreibung

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.

Rezensionen / Stimmen

"Wenn Sie schon immer Go lernen wollten und wenig Lust auf langweilige Programmierbeispiele haben, dürfte Ihnen Ralf Wirdemanns Buch zusagen. Nach dem Durcharbeiten haben Sie sowohl die neue Programmiersprache als auch die Arbeit mit REST erlernt - dank des gelungen kurzen Stoffumfangs zudem in mehr als annehmbarer Zeit." Tam Hanna, Javamagazin, April 2019

Weitere Details

Weitere Ausgaben

Person

Inhalt

1 - Inhalt [Seite 6]
2 - 1 Einleitung [Seite 14]
2.1 - 1.1 Alle bauen APIs [Seite 14]
2.2 - 1.2 Web-Frameworks [Seite 15]
2.3 - 1.3 Alle wollen Go [Seite 15]
2.4 - 1.4 Warum REST? [Seite 16]
2.5 - 1.5 Aufbau des Buches [Seite 17]
2.6 - 1.6 Disclaimer [Seite 17]
2.7 - 1.7 Gebrauchsanleitung [Seite 18]
2.8 - 1.8 Code-Beispiele [Seite 18]
3 - 2 Go [Seite 20]
3.1 - 2.1 Installation [Seite 20]
3.2 - 2.2 Der Go-Workspace [Seite 21]
3.3 - 2.3 Test der Installation [Seite 22]
3.4 - 2.4 Programmstruktur [Seite 22]
3.5 - 2.5 Packages [Seite 23]
3.6 - 2.6 Funktionen [Seite 24]
3.7 - 2.7 Variablen [Seite 24]
3.8 - 2.8 Typen [Seite 25]
3.9 - 2.9 Schleifen [Seite 27]
3.10 - 2.10 Verzweigungen [Seite 28]
3.11 - 2.11 Methoden [Seite 30]
3.12 - 2.12 Pointer [Seite 31]
3.13 - 2.13 Interfaces [Seite 32]
3.14 - 2.14 Arrays und Slices [Seite 34]
3.14.1 - 2.14.1 Arrays [Seite 34]
3.14.2 - 2.14.2 Slices [Seite 34]
3.14.3 - 2.14.3 Polymorphe Arrays [Seite 36]
3.15 - 2.15 Maps [Seite 36]
3.16 - 2.16 Verzögerungen, Panic und Recover [Seite 37]
3.17 - 2.17 Was sonst noch? [Seite 39]
4 - 3 REST [Seite 40]
4.1 - 3.1 Überblick [Seite 40]
4.2 - 3.2 Ressourcen [Seite 42]
4.3 - 3.3 Uniform Ressource Identifier [Seite 42]
4.4 - 3.4 HTTP-Methoden [Seite 43]
4.4.1 - 3.4.1 GET [Seite 43]
4.4.2 - 3.4.2 POST [Seite 44]
4.4.3 - 3.4.3 PUT [Seite 44]
4.4.4 - 3.4.4 DELETE [Seite 44]
4.4.5 - 3.4.5 PATCH [Seite 44]
4.4.6 - 3.4.6 HEAD [Seite 44]
4.4.7 - 3.4.7 OPTIONS [Seite 44]
4.5 - 3.5 Repräsentationen [Seite 45]
4.6 - 3.6 Statuscodes [Seite 45]
4.6.1 - 3.6.1 2xx Erfolg [Seite 46]
4.6.2 - 3.6.2 3xx Umleitung [Seite 46]
4.6.3 - 3.6.3 4xx Client-Fehler [Seite 46]
4.6.4 - 3.6.4 5xx Server-Fehler [Seite 46]
4.7 - 3.7 Hypermedia [Seite 47]
4.8 - 3.8 REST als Architekturstil [Seite 48]
4.8.1 - 3.8.1 Client-Server [Seite 48]
4.8.2 - 3.8.2 Zustandslosigkeit [Seite 48]
4.8.3 - 3.8.3 Cacheability [Seite 49]
4.8.4 - 3.8.4 Uniform Interface [Seite 49]
4.8.5 - 3.8.5 Layered System [Seite 49]
4.8.6 - 3.8.6 Code on Demand [Seite 50]
4.9 - 3.9 Zusammenfassung [Seite 50]
5 - 4 HTTP und JSON [Seite 52]
5.1 - 4.1 Das Package net/http [Seite 52]
5.1.1 - 4.1.1 Request Handling [Seite 52]
5.1.2 - 4.1.2 Level-2-Services [Seite 56]
5.2 - 4.2 Das Package encoding/json [Seite 58]
5.2.1 - 4.2.1 JSON-Encoding [Seite 59]
5.2.2 - 4.2.2 JSON-Decoding [Seite 61]
5.3 - 4.3 HTTP und JSON [Seite 62]
5.4 - 4.4 Abschluss [Seite 63]
6 - 5 Restvoice [Seite 64]
6.1 - 5.1 Vision [Seite 64]
6.2 - 5.2 Use Cases [Seite 65]
6.3 - 5.3 Domainmodell [Seite 66]
6.4 - 5.4 Ressourcen [Seite 68]
6.5 - 5.5 Kern-Use-Cases [Seite 68]
6.5.1 - 5.5.1 Rechnung erstellen [Seite 70]
6.5.2 - 5.5.2 Buchung zufügen [Seite 73]
6.5.3 - 5.5.3 Buchung löschen [Seite 76]
6.5.4 - 5.5.4 Rechnung abschließen [Seite 77]
6.5.5 - 5.5.5 Rechnung zustellen [Seite 78]
6.6 - 5.6 Kritik am Entwurf [Seite 79]
6.6.1 - 5.6.1 Sicherheit [Seite 79]
6.6.2 - 5.6.2 Testbarkeit [Seite 80]
6.6.3 - 5.6.3 Kopplung [Seite 80]
6.6.4 - 5.6.4 RESTfulness [Seite 81]
6.7 - 5.7 Warum Go? [Seite 81]
6.8 - 5.8 Abschluss [Seite 82]
7 - 6 Design [Seite 84]
7.1 - 6.1 Layering [Seite 85]
7.2 - 6.2 Domain-driven Design [Seite 85]
7.3 - 6.3 Hexagonale Architektur [Seite 86]
7.3.1 - 6.3.1 Beispiel [Seite 88]
7.3.2 - 6.3.2 Der Use Case ELIZA [Seite 88]
7.3.3 - 6.3.3 Ports und Adapter [Seite 89]
7.4 - 6.4 Use Case "Rechnung erstellen" [Seite 90]
7.4.1 - 6.4.1 HTTP Invoice [Seite 91]
7.4.2 - 6.4.2 Geschäftslogik [Seite 92]
7.4.3 - 6.4.3 Invoice HTTP [Seite 93]
7.4.4 - 6.4.4 Bootstrapping [Seite 93]
7.5 - 6.5 Use Case "Tätigkeit buchen" [Seite 95]
7.6 - 6.6 Use Case "Rechnung abschließen" [Seite 96]
7.7 - 6.7 Use Case "Rechnung anfordern" [Seite 98]
7.8 - 6.8 Was haben wir erreicht? [Seite 99]
7.8.1 - 6.8.1 Entkopplung [Seite 100]
7.8.2 - 6.8.2 Wartbarkeit [Seite 100]
7.8.3 - 6.8.3 Testbarkeit [Seite 101]
8 - 7 Testing [Seite 102]
8.1 - 7.1 Unit Tests [Seite 102]
8.2 - 7.2 Unit Tests in Go [Seite 103]
8.3 - 7.3 HTTP-Tests in Go [Seite 105]
8.4 - 7.4 Was testen? [Seite 106]
8.5 - 7.5 Beispiel: Rechnung abschließen [Seite 107]
8.5.1 - 7.5.1 Testszenario [Seite 108]
8.5.2 - 7.5.2 Method under Test [Seite 108]
8.5.3 - 7.5.3 Unit Test [Seite 110]
8.5.4 - 7.5.4 Integrationstest [Seite 110]
8.6 - 7.6 Fake- und Mock-Objekte [Seite 112]
8.6.1 - 7.6.1 Fake-Objekte [Seite 112]
8.6.2 - 7.6.2 Mock-Objekte [Seite 114]
8.7 - 7.7 Unit Test mit Fake-Objekt [Seite 115]
8.8 - 7.8 HTTP-Test [Seite 115]
8.9 - 7.9 API-Test [Seite 116]
8.10 - 7.10 Testseparation [Seite 118]
8.10.1 - 7.10.1 Build Tags: -tags [Seite 118]
8.10.2 - 7.10.2 Short Modus: -short [Seite 119]
8.10.3 - 7.10.3 Einzelne Tests ausführen: -run [Seite 119]
8.11 - 7.11 Test Coverage [Seite 119]
8.12 - 7.12 Abschluss [Seite 121]
9 - 8 Hypermedia als Motor [Seite 122]
9.1 - 8.1 HATEOAS [Seite 123]
9.2 - 8.2 Hypermedia Rechnungsstellung [Seite 123]
9.2.1 - 8.2.1 Zustandsübergänge [Seite 124]
9.2.2 - 8.2.2 Wie sage ich es meinem Client? [Seite 125]
9.3 - 8.3 Hypertext Application Language [Seite 126]
9.4 - 8.4 HAL in Go [Seite 129]
9.4.1 - 8.4.1 Geschäftslogik [Seite 129]
9.4.2 - 8.4.2 Media Type "application/hal+json" [Seite 130]
9.5 - 8.5 Hypermedia-Clients [Seite 132]
9.6 - 8.6 Resource Expansion [Seite 134]
9.7 - 8.7 CRUD vs. Hypermedia [Seite 137]
9.8 - 8.8 Abschluss [Seite 138]
10 - 9 Sicherheit [Seite 140]
10.1 - 9.1 Client-Authentifizierung [Seite 140]
10.1.1 - 9.1.1 HTTP Basic [Seite 141]
10.1.2 - 9.1.2 HTTP Digest [Seite 145]
10.1.3 - 9.1.3 JSON Web Token [Seite 147]
10.2 - 9.2 Server-Authentifizierung [Seite 152]
10.3 - 9.3 Autorisierung [Seite 154]
10.4 - 9.4 Verschlüsselung [Seite 156]
10.5 - 9.5 Abschluss [Seite 157]
11 - 10 Skalierbarkeit [Seite 160]
11.1 - 10.1 Horizontale Skalierung [Seite 160]
11.2 - 10.2 Zustandslosigkeit [Seite 161]
11.2.1 - 10.2.1 Sitzungsstatus [Seite 161]
11.2.2 - 10.2.2 Clientstatus [Seite 161]
11.2.3 - 10.2.3 Ressourcenstatus [Seite 162]
11.3 - 10.3 Restvoice skalieren [Seite 163]
11.4 - 10.4 Vertikale Skalierung [Seite 163]
11.4.1 - 10.4.1 Go-Routinen [Seite 164]
11.4.2 - 10.4.2 Restvoice vertikal skalieren [Seite 164]
11.5 - 10.5 Abschluss [Seite 166]
12 - 11 Caching [Seite 168]
12.1 - 11.1 Arten von Caches [Seite 168]
12.1.1 - 11.1.1 Lokaler Cache [Seite 168]
12.1.2 - 11.1.2 Proxy Cache [Seite 169]
12.1.3 - 11.1.3 Reverse Proxy Cache [Seite 169]
12.2 - 11.2 HTTP Caching [Seite 169]
12.2.1 - 11.2.1 GET [Seite 169]
12.2.2 - 11.2.2 Cachebare Responses [Seite 169]
12.2.3 - 11.2.3 Cache-Validierung [Seite 170]
12.2.4 - 11.2.4 Cache-Invalidierung [Seite 172]
12.3 - 11.3 Restvoice Caching [Seite 172]
12.4 - 11.4 Activity Caching [Seite 172]
12.4.1 - 11.4.1 Cacheable Responses [Seite 172]
12.4.2 - 11.4.2 Cache-Validierung [Seite 174]
12.4.3 - 11.4.3 Invalidierung [Seite 176]
12.4.4 - 11.4.4 Alternative ETags [Seite 177]
12.5 - 11.5 Abschluss [Seite 177]
13 - 12 Wie geht es weiter? [Seite 178]
13.1 - 12.1 Danke! [Seite 178]
13.2 - 12.2 Feedback [Seite 179]
14 - Literatur [Seite 180]
15 - Stichwortverzeichnis [Seite 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 https://golang.org/dl/ bereit. Unter MacOS wird die Go-Distribution nach /usr/local/go installiert. Damit die Go-Tools im Terminal funktionieren, muss die PATH-Variable um den Pfad /usr/local/go/bin erweitert werden. Führen Sie das Go-Tool in einem neuen Terminalfenster mit dem Parameter version aus:

$ go version go version go1.11 darwin/amd64

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 https://golang.org/doc/install.

2.2 Der Go-Workspace

Das grundlegende Konzept einer Go-Entwicklungsumgebung ist der Go-Workspace. Der Go-Workspace ist ein zentrales Verzeichnis, das über die Umgebungsvariable GOPATH referenziert wird. Unterhalb des GOPATH finden sich die drei Unterverzeichnisse bin, pkg und src:

bin/ restvoice pkg/ linux_amd64/ github.com/rwirdemann/restvoice/ usecase.a src/ github.com/rwirdemann/restvoice/ main.go usecase/ create_invoice.go

Go-Programmewerden compiliert und zu einem statischen Binary gelinkt. Die resultierende Binärdatei landet im Verzeichnis bin des Go-Workspace. Zusammengehörige Dateien, sogenannte Packages, werden zu einer package. a-Datei übersetzt und in eines der plattformspezifischen Unterverzeichnisse von pkg abgelegt. Das Unterverzeichnis src 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 Vendoring erweitert. Mit Vendoring kann man einem Projekt weitere Abhängigkeiten aus einem projektlokalen vendor-Verzeichnis zufügen. Seit Go-Version 1.11 steht mit Go Modules eine Ablösung des Vendoring ins Haus. Die Beispiele in diesem Buch funktionieren GOPATH-basiert. Die Beschäftigung mit Vendoring oder besser Go Modules 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 bin, pkg und src und exportieren Sie dessen Verzeichnis in der Umgebungsvariable GOPATH:

$ cd $HOME $ mkdir -p go/bin go/pkg go/src $ export GOPATH=$HOME/go

Anschließend wird im Verzeichnis src eine Datei main.go mit folgendem Inhalt erstellt:

1 package main 2 3 func main() { 4 println("Hello, Jo") 5 }

Die Funktion main im Package main ist der Einstiegspunkt in ein Go-Programm und wird beim Start des Programms ausgeführt. Das Kommando go run compiliert und führt das Programm aus:

$ cd $GOPATH/src $ go run main Hello, Jo

Das Kommandozeilentool go ist das zentrale Werkzeug einer Go-Distribution. Entsprechend parametrisiert lassen sich damit alle wichtigen Entwicklungsaufgaben ausführen. Einige Beispiele:

go build main.go # Übersetzt und legt das Binary im aktuellen Verzeichnis ab go install main.go # Übersetzt und legt das Binary im Verzeichnis "bin" ab go test # Führt die Tests im aktuellen Package aus

Ein vollständige Dokumentation der Go-Tools finden Sie unter https://golang.org/cmd/go.

2.4 Programmstruktur

Go-Quellcode ist auf Dateien mit dem Suffix .go verteilt. Die Struktur einer Go-Datei wird auf oberster Ebene durch sechs Keywords bestimmt:

package import var const type func

Das erste Statement einer Go-Datei ist immer package, gefolgt von einem oder mehreren import-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 memory.go im Verzeichnis $GOPATH/go101/cache und gehört zum Package cache:

1 package cache 2 3 func Write(key string, value string) { 4 ... 5 }

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 import-Statement importiert. Öffentliche Typen, Variablen und Funktionen werden genutzt, indem der Package-Name dem importierten Element vorangestellt wird:

1 package main 2 3 import "cache" 4 5 func main() { 6 cache.Write("1", "Kalle") 7 }

Die Funktion main importiert das Package cache und ruft die exportierte Funktion cache. Write auf. Das main-Beispiel zeigt eine Ausnahme in Bezug auf die Namenskonvention für Packages: Die Go-Datei mit der Funktion main gehört zum Package main, unabhängig vom Verzeichnis, in dem sie liegt.

Initialisierung

Jede Datei eines Packages kann eine init-Funktion enthalten, in der paketweite Initialisierungsaufgaben ausgeführt werden. Init-Funktionen werden beim Laden eines Packages automatisch ausgeführt:

1 package auth 2 3 var kf []byte 4 5 func init() { 6 if kf, err := ioutil.ReadFile("public.key"); err != nil { 7 log.Fatalf("Could not open public key file: %s", "public.key") 8 } 9 }

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 init, 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:

import _ "github.com/go-sql-driver/mysql"

Der Import...

Inhalt (PDF)

Systemvoraussetzungen

Dateiformat: ePUB
Kopierschutz: Wasserzeichen-DRM (Digital Rights Management)

Systemvoraussetzungen:

Computer (Windows; MacOS X; Linux): Verwenden Sie eine Lese-Software, die das Dateiformat ePUB verarbeiten kann: z.B. Adobe Digital Editions oder FBReader – beide kostenlos (siehe E-Book Hilfe).
Tablet/Smartphone (Android; iOS): Installieren Sie die App Adobe Digital Editions oder eine andere Leseapp für E-Books, z.B. PocketBook (siehe E-Book Hilfe).
E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m.

Das Dateiformat ePUB ist sehr gut für Romane und Sachbücher geeignet - also für „fließenden” Text ohne komplexes Layout. Bei E-Readern oder Smartphones passt sich der Zeilen- und Seitenumbruch automatisch den kleinen Displays an.
Mit Wasserzeichen-DRM wird hier ein „weicher” Kopierschutz verwendet. Daher ist technisch zwar alles möglich – sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.

Weitere Informationen finden Sie in unserer E-Book Hilfe.

Dateiformat: PDF
Kopierschutz: Wasserzeichen-DRM (Digital Rights Management)

Systemvoraussetzungen:

Computer (Windows; MacOS X; Linux): Verwenden Sie zum Lesen die kostenlose Software Adobe Reader, Adobe Digital Editions oder einen anderen PDF-Viewer Ihrer Wahl (siehe E-Book Hilfe).
Tablet/Smartphone (Android; iOS): Installieren Sie bereits vor dem Download die kostenlose App Adobe Digital Editions oder die App PocketBook (siehe E-Book Hilfe).
E-Book-Reader: Bookeen, Kobo, Pocketbook, Sony, Tolino u.v.a.m.

Das Dateiformat PDF zeigt auf jeder Hardware eine Buchseite stets identisch an. Daher ist eine PDF auch für ein komplexes Layout geeignet, wie es bei Lehr- und Fachbüchern verwendet wird (Bilder, Tabellen, Spalten, Fußnoten). Bei kleinen Displays von E-Readern oder Smartphones sind PDF leider eher nervig, weil zu viel Scrollen notwendig ist. Mit Wasserzeichen-DRM wird hier ein „weicher” Kopierschutz verwendet. Daher ist technisch zwar alles möglich – sogar eine unzulässige Weitergabe. Aber an sichtbaren und unsichtbaren Stellen wird der Käufer des E-Books als Wasserzeichen hinterlegt, sodass im Falle eines Missbrauchs die Spur zurückverfolgt werden kann.

Weitere Informationen finden Sie in unserer E-Book Hilfe.

Als PDF speichern Als Link merken