REST und HTTP (eBook)
330 Seiten
dpunkt (Verlag)
978-3-86491-643-4 (ISBN)
Stefan Tilkov beschäftigt sich seit Beginn der 90er-Jahre mit Architekturansätzen fu?r große, verteilte Systemlandschaften. Von 1993 bis 1998 war er in verschiedenen Rollen bei einem mittelständischen Softwarehaus tätig, zuletzt als Leiter des Bereichs Anwendungsentwicklung, bevor er 1999 die Technologieberatung innoQ Deutschland GmbH mitgru?ndete. Als Geschäftsfu?hrer und Principal Consultant beschäftigt er sich dort schwerpunktmäßig mit leichtgewichtigen Architekturansätzen und serviceorientierten IT-Architekturen. Martin Eigenbrodt ist seit 2009 Mitarbeiter bei innoQ. Als Senior Consultant gehört sowohl die Schulung und Beratung beim Entwurf von RESTful APIs zu seinen Aufgaben, als auch deren konkrete Implementierung. Technologisch liegt sein Schwerpunkt dabei auf Scala und Play. Silvia Schreier beschäftigt sich seit einigen Jahren mit REST. Zunächst im Rahmen ihrer Tätigkeit als wissenschaftliche Mitarbeiterin an der FernUniversität in Hagen und seit 2013 als Consultant bei innoQ. Dort liegt ihr Schwerpunkt auf dem Entwurf und der Entwicklung REST- und ROCA-konformer Anwendungen mit verschiedensten Programmiersprachen und Persistenzlösungen. Außerdem versucht sie bei Veranstaltungen verschiedenster Initiativen andere Menschen fu?r die IT zu begeistern. Oliver Wolf beschäftigt sich seit vielen Jahren mit Software- und Systemarchitektur und interessiert sich besonders fu?r große, verteilte Systeme mit hohen Anforderungen an Sicherheit, Skalierbarkeit und Flexiblität. Bevor er als Principal Consultant zu innoQ kam, war er unter anderem als Chefarchitekt, Technischer Produktmanager und Berater bei verschiedenen IT-Unternehmen tätig.
Stefan Tilkov beschäftigt sich seit Beginn der 90er-Jahre mit Architekturansätzen für große, verteilte Systemlandschaften. Von 1993 bis 1998 war er in verschiedenen Rollen bei einem mittelständischen Softwarehaus tätig, zuletzt als Leiter des Bereichs Anwendungsentwicklung, bevor er 1999 die Technologieberatung innoQ Deutschland GmbH mitgründete. Als Geschäftsführer und Principal Consultant beschäftigt er sich dort schwerpunktmäßig mit leichtgewichtigen Architekturansätzen und serviceorientierten IT-Architekturen. Martin Eigenbrodt ist seit 2009 Mitarbeiter bei innoQ. Als Senior Consultant gehört sowohl die Schulung und Beratung beim Entwurf von RESTful APIs zu seinen Aufgaben, als auch deren konkrete Implementierung. Technologisch liegt sein Schwerpunkt dabei auf Scala und Play. Silvia Schreier beschäftigt sich seit einigen Jahren mit REST. Zunächst im Rahmen ihrer Tätigkeit als wissenschaftliche Mitarbeiterin an der FernUniversität in Hagen und seit 2013 als Consultant bei innoQ. Dort liegt ihr Schwerpunkt auf dem Entwurf und der Entwicklung REST- und ROCA-konformer Anwendungen mit verschiedensten Programmiersprachen und Persistenzlösungen. Außerdem versucht sie bei Veranstaltungen verschiedenster Initiativen andere Menschen für die IT zu begeistern. Oliver Wolf beschäftigt sich seit vielen Jahren mit Software- und Systemarchitektur und interessiert sich besonders für große, verteilte Systeme mit hohen Anforderungen an Sicherheit, Skalierbarkeit und Flexiblität. Bevor er als Principal Consultant zu innoQ kam, war er unter anderem als Chefarchitekt, Technischer Produktmanager und Berater bei verschiedenen IT-Unternehmen tätig.
Vorbemerkung zur dritten Auflage 6
Vorbemerkung zur zweiten Auflage 8
Vorwort zur ersten Auflage 10
Danksagung 12
1 Einleitung 22
1.1 Warum REST? 22
1.1.1 Lose Kopplung 23
1.1.2 Interoperabilität 24
1.1.3 Wiederverwendung 24
1.1.4 Performance und Skalierbarkeit 25
1.2 Zielgruppe und Voraussetzungen 25
1.3 Zur Struktur des Buches 26
2 Einführung in REST 30
2.1 Eine kurze Geschichte von REST 30
2.2 Grundprinzipien 32
2.3 Zusammenfassung 40
3 Fallstudie: OrderManager 42
3.1 Fachlicher Hintergrund 42
3.2 Ressourcen 44
3.2.1 Bestellungen 44
3.2.2 Bestellungen in unterschiedlichen Zuständen 51
3.2.3 Stornierungen 51
3.3 Repräsentationen 53
3.4 Zusammenfassung 54
4 Ressourcen 56
4.1 Ressourcen und Repräsentationen 56
4.2 Ressourcendesign 57
4.2.1 Primärressourcen 58
4.2.2 Subressourcen 59
4.2.3 Listen 59
4.2.4 Projektionen 60
4.2.5 Aggregationen 60
4.2.6 Aktivitäten 60
4.2.7 Konzept- und Informationsressourcen 60
4.2.8 Evolutionäre Weiterentwicklung und YAGNI 61
4.3 Ressourcenidentifikation und URIs 61
4.3.1 URI, IRI, URL, URN, XRI? 62
4.3.2 Anatomie einer HTTP-URI 63
4.3.3 URI-Templates 67
4.4 URI-Design 68
4.4.1 URI-Entwurfsgrundsätze 68
4.4.2 REST aus Versehen 71
4.4.3 Stabile URIs 72
4.5 Zusammenfassung 73
5 Verben 74
5.1 Standardverben von HTTP 1.1 74
5.1.1 GET 74
5.1.2 HEAD 76
5.1.3 PUT 77
5.1.4 POST 78
5.1.5 DELETE 78
5.1.6 OPTIONS 79
5.1.7 TRACE und CONNECT 79
5.2 HTTP-Verben in der Praxis 79
5.3 Tricks für PUT und DELETE 80
5.3.1 HTML-Formulare 80
5.3.2 Firewalls und eingeschränkte Clients 82
5.4 Definition eigener Methoden 84
5.4.1 WebDAV 84
5.4.2 Partial Updates und PATCH 86
5.4.3 Multi-Request-Verarbeitung 87
5.5 LINK und UNLINK 89
5.6 Zusammenfassung 90
6 Hypermedia 92
6.1 Hypermedia im Browser 92
6.2 HATEOAS und das »Human Web« 96
6.3 Hypermedia in der Anwendung-zu-Anwendung- Kommunikation 98
6.4 Ressourcenverknüpfung 99
6.5 Einstiegspunkte 99
6.6 Aktionsrelationen 101
6.7 Darstellung von Links und das < link>
6.8 Standardisierung von Link-Relationen 105
6.9 Zusammenfassung 106
7 Repräsentationsformate 108
7.1 Formate, Medientypen und Content Negotiation 108
7.2 JSON 109
7.2.1 HAL 110
7.2.2 Collection+JSON 113
7.2.3 SIREN 115
7.2.4 Fazit 117
7.3 XML 118
7.4 HTML/XHTML 119
7.5 Textformate 122
7.5.1 Plaintext 122
7.5.2 URI-Listen 123
7.6 CSV 123
7.7 RSS und Atom 124
7.8 Binäre Formate 126
7.9 Microformats 127
7.10 RDF 128
7.11 Zusammenfassung 130
8 Fallstudie: AtomPub 132
8.1 Historie 132
8.2 Discovery und Metadaten 133
8.3 Ressourcentypen 136
8.4 REST und Atom/AtomPub 138
8.5 Zusammenfassung 138
9 Sitzungen und Skalierbarkeit 140
9.1 Cookies 141
9.2 Ressourcen- und Clientstatus 143
9.3 Skalierbarkeit und »Shared Nothing«-Architektur 145
9.4 Zusammenfassung 147
10 Caching 148
10.1 Expirationsmodell 148
10.2 Validierungsmodell 150
10.3 Cache-Topologien 152
10.4 Caching und Header 155
10.4.1 Response-Header 155
10.4.2 Request-Header 156
10.5 Schwache ETags 156
10.6 Invalidierung 157
10.7 Caching und personalisierte Inhalte 158
10.8 Caching im Internet 158
10.9 Zusammenfassung 159
11 Sicherheit 160
11.1 SSL und HTTPS 160
11.2 Authentisierung, Authentifizierung, Autorisierung 161
11.3 HTTP-Authentifizierung 162
11.4 HTTP Basic Authentication 163
11.5 Der 80%-Fall: HTTPS + Basic-Auth 164
11.6 HTTP Digest Authentication 166
11.7 Browser-Integration und Cookies 168
11.8 HMAC 170
11.9 OpenID 171
11.10 OAuth 172
11.10.1 OAuth 1.0 173
11.10.2 OAuth 2.0 173
11.11 Autorisierung 175
11.12 Nachrichtenverschlüsselung und Signatur 176
11.13 Zusammenfassung 177
12 Dokumentation 178
12.1 Selbstbeschreibende Nachrichten 179
12.2 Hypermedia 180
12.3 HTML als Standardformat 180
12.4 Beschreibungsformate 181
12.4.1 WSDL 181
12.4.2 WADL 182
12.4.3 Swagger, RAML und API Blueprint 185
12.4.4 RDDL 189
12.5 Zusammenfassung 192
13 Erweiterte Anwendungsfälle 194
13.1 Asynchrone Verarbeitung 194
13.1.1 Notifikation per HTTP-»Callback« 196
13.1.2 Polling 197
13.2 Zuverlässigkeit 198
13.2.1 PUT statt POST 201
13.2.2 POST-PUT-Kombination 203
13.2.3 Reliable POST 204
13.3 Transaktionen 205
13.3.1 Atomare (Datenbank-)Transaktionen 205
13.3.2 Verteilte Transaktionen 206
13.3.3 Fachliche Transaktionen 206
13.4 Parallelzugriff und konditionale Verarbeitung 207
13.5 Versionierung 208
13.5.1 Zusätzliche Ressourcen 209
13.5.2 Erweiterbare Datenformate 209
13.5.3 Versionsabhängige Repräsentationen 210
13.6 Zusammenfassung 210
14 Fallstudie: OrderManager, Iteration 2 212
14.1 OrderEntry 213
14.1.1 Medientypen 213
14.1.2 Servicedokumentation 216
14.1.3 Bestellpositionen 220
14.1.4 Zustandsänderungen 221
14.2 Fulfilment 226
14.2.1 Notifikation über neue Bestellungen 226
14.2.2 Bestellübernahme 228
14.2.3 Produktionsaufträge 233
14.2.4 Versandfristen 234
14.2.5 Lieferdatum 234
14.3 Reporting 236
14.4 Zusammenfassung 238
15 Architektur und Umsetzung 240
15.1 Architekturebenen 240
15.2 Domänenarchitektur 241
15.2.1 Systemgrenzen und Ressourcen 242
15.2.2 Medientypen und Kontrakte 243
15.2.3 Identität und Adressierbarkeit 245
15.3 Softwarearchitektur 246
15.3.1 Schichten 247
15.3.2 Domänenmodell 248
15.3.3 Nutzung von Diensten 249
15.4 Systemarchitektur 251
15.4.1 Netztopologie 251
15.4.2 Caching 252
15.4.3 Firewalls 253
15.5 Frontend-Architektur 254
15.5.1 Benutzerschnittstellen und RESTful-HTTP-Backends 255
15.5.2 Sinn und Unsinn von Portalen 257
15.6 Web-API-Architektur 258
15.7 Zusammenfassung 261
16 »Enterprise REST«: SOA auf Basis von RESTful HTTP 262
16.1 SOA-Definitionen 262
16.2 Business/IT-Alignment 265
16.3 Governance 266
16.3.1 Daten- und Schnittstellenbeschreibungen 267
16.3.2 Registry/Repository-Lösungen 268
16.3.3 Discovery 268
16.4 Orchestrierung und Choreografie 269
16.5 Enterprise Service Bus (ESB) 270
16.6 WSDL, SOAP & WS-*: WS-Architektur
16.7 Zusammenfassung 274
17 Weboberflächen mit ROCA 276
17.1 REST: Nicht nur für Webservices 276
17.2 Clientaspekte von ROCA 279
17.2.1 Semantisches HTML 280
17.2.2 CSS 281
17.2.3 Die Rolle von JavaScript 282
17.2.4 Unobtrusive JavaScript und Progressive Enhancement 284
17.3 ROCA vs. Single Page Apps 285
17.4 Zusammenfassung 286
A HTTP-Statuscodes 290
B Fortgeschrittene HTTP-Mechanismen 296
B.1 Persistente Verbindungen 296
B.2 Request-Pipelining 296
B.3 Range Requests 297
B.4 Chunked Encoding 297
C Werkzeuge und Bibliotheken 300
C.1 Kommandozeilen-Clients 300
C.2 HTTP-Server 301
C.3 Caches 302
C.4 Programmierumgebungen 303
C.4.1 Java/JVM-Sprachen 303
C.4.2 Microsoft .NET 306
C.4.3 Ruby 307
C.4.4 Python, Perl, Node.js & Co
D HTTP/2 und SPDY 310
D.1 Geschichte von HTTP 310
D.2 SPDY 311
D.3 HTTP/2 312
Index 326
www.dpunkt.de 0
1 Einleitung
Es gibt unzählige Wege, um Systeme miteinander zu verbinden. Wenn Sie schon eine Weile als Entwickler oder Architekt in der IT-Branche tätig sind, haben Sie eine Reihe davon wahrscheinlich persönlich miterlebt: einfache Kommunikation über Sockets, Shared Memory oder Named Pipes, Abstraktionen wie Remote Procedure Call (RPC), proprietäre oder standardisierte Ansätze wie DCOM und CORBA, RMI und Webservices. Warum sollten Sie sich mit einem weiteren Ansatz beschäftigen? Eine ähnliche Frage hat sich wohl jeder gestellt, als er (oder sie) das erste Mal von »REST« hörte. Was soll daran schon neu oder anders sein? Ist es nicht völlig irrelevant, welche Technologie man einsetzt? Sind die Architekturmuster nicht die gleichen?
1.1 Warum REST?
Nach einer durchaus längeren Phase der Skepsis sind wir zu dem Ergebnis gekommen, dass sich hinter REST [Fielding2000] tatsächlich etwas Neues verbirgt. Wir sind überzeugt davon, dass viele der Innovationen, die im Kontext der Erfindung des WWW entstanden sind, revolutionäre Auswirkungen auf die Architektur unserer IT-Systeme haben können. Dazu gehören keine prophetischen Fähigkeiten – kaum jemand wird bestreiten, dass das WWW tatsächlich eine bahnbrechende technologische Entwicklung war. Aber obwohl wir alle das Web täglich benutzen und man daher annehmen könnte, dass wir es verstanden haben, nutzen wir häufig sein Potenzial bei Weitem nicht aus. Das gilt sowohl für Anwendungen, die über eine Weboberfläche verfügen, wie für verteilte Systeme, die auf Basis von Webtechnologien miteinander kommunizieren. Der Grund dafür ist eine unzureichende Kenntnis der Webarchitektur mit ihrem wichtigsten Protokoll HTTP [RFC7230]1, die ihrerseits wiederum eine konkrete Ausprägung des Architekturstils REST ist2.
Wenn Sie bislang mit Technologien wie verteilten Objekten (Distributed Objects) oder entfernten Prozeduraufrufen (Remote Procedure Call) gearbeitet haben, werden Ihnen viele Ideen aus REST sehr ungewöhnlich erscheinen. Aber auch wenn Sie bereits Webanwendungen entwickelt haben und HTTP, URIs3 und viele andere Standards aus diesem Umfeld zu kennen glauben, ist die Wahrscheinlichkeit groß, dass Sie diese nicht konform zu den REST-Prinzipien eingesetzt haben. Zumindest ging es uns so, als wir uns das erste Mal mit REST auseinandersetzten.
In den folgenden Abschnitten möchten wir Sie davon überzeugen, dass es sich lohnt, einer bestimmten Klasse von Problemen mit dem Lösungsansatz REST zu begegnen. Schauen wir uns dazu zunächst einmal an, mit welchen Problemen man sich bei der Gestaltung verteilter Systeme, sowohl im Unternehmen wie auch über Unternehmensgrenzen hinweg, typischerweise auseinandersetzen muss und welchen Beitrag REST und HTTP dazu leisten.
1.1.1 Lose Kopplung
Wenn Sie zwei Systeme so eng aneinander koppeln, dass sie nicht mehr trennbar sind, haben Sie sie zu einem System verschmolzen. Auch wenn das manchmal sogar sinnvoll sein mag: In den meisten Fällen möchten Sie eine modulare Welt von möglichst unabhängigen Teilsystemen anstelle von monolithischen Riesensystemen, die wir nur im Ganzen oder überhaupt nicht einsetzen, aktualisieren, modifizieren oder außer Betrieb nehmen können. Wir bemühen uns deshalb, Systeme über Schnittstellen miteinander kommunizieren zu lassen und sie dabei voneinander zu isolieren. Am unabhängigsten sind zwei Systeme, wenn sie überhaupt nicht gekoppelt sind – sprich: gar nicht miteinander kommunizieren. Ist dies nicht möglich, sollten wir eine Kopplung anstreben, die nur so eng ist, wie es für eine effiziente Kommunikation unbedingt notwendig ist.
Der Begriff »Lose Kopplung« wurde in den vergangenen Jahren insbesondere im Zusammenhang mit serviceorientierten Architekturen (SOA) stark strapaziert. SOA als Konzept wird häufig mit der technologischen Umsetzung durch Webservices auf Basis von SOAP und WSDL assoziiert. Tatsächlich aber führen gerade entscheidende Unterschiede im REST-Modell, wie die uniforme Schnittstelle und Hypermedia – also die Verknüpfung mithilfe von Links –, zu einem erheblichen Mehrwert bei der Entkopplung von Systemen und Services. Auch REST ist kein Wundermittel und kann die Kopplung zwischen zwei Systemen nicht vollständig verhindern, sie lässt sich aber erheblich reduzieren.
Wenn das für Sie zu schön klingt, um wahr sein zu können, hilft vielleicht ein Blick auf den verbreitetsten aller REST-Clients: Der Webbrowser, den Sie tagtäglich benutzen, ist an keinen bestehenden Server konkret gekoppelt, sondern auf Basis der uniformen Standardschnittstelle in der Lage, mit beliebigen Servern zu kommunizieren, die ihre Dienste über HTTP zur Verfügung stellen. Wir werden sehen, dass es eines der zentralen Ziele bei der Entwicklung von Systemen nach dem REST-Stil ist, diese Art der Entkopplung zwischen Kommunikationspartnern zu erreichen.
1.1.2 Interoperabilität
Interoperabilität, die Möglichkeit zur Kommunikation von Systemen mit technisch stark unterschiedlicher Implementierung, ergibt sich aus der Festlegung auf gemeinsame Standards. So ist die Steckdose in der Wand kompatibel mit dem Netzstecker eines Gerätes, zumindest, wenn sich beide an Standards aus dem gleichen Geltungsbereich, dem gleichen »Ökosystem«, halten. In dieser Beziehung sind die Standards des Web – HTTP, URIs, XML, aber auch HTML u.a. – unschlagbar: Keine andere Softwaretechnologie ist in Bezug auf die Größe des Geltungsbereichs so umfassend wie HTTP4. Im Umkehrschluss kann die Festlegung auf eine bestimmte Technologie zur Hürde für die Kommunikation mit einem System werden. Selbst definierte Binärprotokolle, der Austausch von CSV-oder XML-Dateien, kommerzielle Middleware-Produkte, COM, CORBA, RMI oder SOAP über HTTP: Jeder dieser Ansätze bringt seine eigene Komplexität und seine eigenen Anforderungen an die Umgebung der Kommunikationspartner mit sich. HTTP als Protokoll und URIs als Identifikationsmechanismus werden in praktisch jeder Umgebung unterstützt, vom Großrechner bis zum Embedded-System (in meinem WLAN-Router z. B. arbeitet ein HTTP-Server). Kein anderes Applikationsprotokoll ist HTTP in Bezug auf die Interoperabilität überlegen.
1.1.3 Wiederverwendung
Schon andere Technologien wurden damit beworben, durch massiv höhere Wiederverwendungsraten die Kosten in der Softwareerstellung zu senken – seien es Objekte, Komponenten oder Services. Bei der Entwicklung von REST-Anwendungen spielen zwei Faktoren hier eine zusätzliche Rolle: die Möglichkeit von sich überlappenden Schnittstellen und die Unterstützung der ungeplanten Wiederverwendung (»serendipitous reuse«) [Vinoski2008].
Ein typisches Problem bei einem Entwurf, der eine später Wiederverwendung unterstützen soll, ist die mangelhafte Vorhersehbarkeit der Anforderungen. Nahezu alle bereits oben aufgezählten Technologien zielen darauf ab, eine klare, formal definierte Schnittstelle für jede spezifische Anwendung zu erfinden. Schnittstellendesign ist jedoch keine leichte Aufgabe – idealerweise vereinheitlicht man eine Reihe bestehender Lösungen, erprobt das Ergebnis und standardisiert es anschließend. Bei REST gibt es nur eine Schnittstelle. Dadurch kann jeder Client, der diese Schnittstelle verwenden kann, mit jedem REST-basierten Service kommunizieren (unter der Voraussetzung, dass das Datenformat von beiden Seiten verstanden wird).
1.1.4 Performance und Skalierbarkeit
Benutzergesteuerte Anwendungen und von anderen Programmen aufgerufene Dienste sollen schnell antworten – so schnell wie möglich. Gleichzeitig soll eine größtmögliche Anzahl von Anfragen in einem definierten Zeitraum beantwortet werden können.
Wie performant und skalierbar eine Anwendung oder ein Service ist, hängt vor allem von der Architektur ab, und zwar auf zwei Ebenen: zum einen der internen Architektur, also der der Implementierung, zum anderen der Verteilungsarchitektur, also der Art und Weise, wie die auf mehrere Prozesse auf unterschiedlichen Rechnerknoten verteilten Komponenten über das Netz miteinander kommunizieren. REST und HTTP haben keinen oder zumindest nur einen geringen Einfluss auf die interne Implementierungsarchitektur, aber einen sehr großen Einfluss auf die externe Verteilungsarchitektur.
Die Infrastruktur des Web kann ihre Stärken optimal ausspielen, wenn die externe Schnittstelle eines Systems auf Basis von HTTP konform zu den REST-Prinzipien entworfen wird. Eine Vielzahl von Anfragen können aus einem Cache beantwortet werden, andere wiederum werden minimiert oder ganz vermieden. Die Skalierbarkeit wird durch den Verzicht auf einen sitzungsbezogenen Status deutlich verbessert – aufeinander folgende Anfragen müssen nicht zwingend vom gleichen System beantwortet werden.
1.2 Zielgruppe und Voraussetzungen
Dieses Buch richtet sich an Architekten, Designer und Entwickler, die »RESTful Services« für die Implementierung einer verteilten Anwendung oder Anwendungslandschaft einsetzen wollen, eine bestehende Webanwendung um eine externe Schnittstelle (ein »Web-API«) erweitern möchten oder ganz...
| Erscheint lt. Verlag | 6.5.2015 |
|---|---|
| Verlagsort | Heidelberg |
| Sprache | deutsch |
| Themenwelt | Mathematik / Informatik ► Informatik ► Programmiersprachen / -werkzeuge |
| Schlagworte | Architektur • Best Practices • Caching • HAL • hyperlinks • JSON • RESTful HTTP • ROCA-Prinzip • Siren • SOA • Softewarearchitektur • URIs • Webanwendungen • Web-API • Web-Services • WebServices • WOA |
| ISBN-10 | 3-86491-643-7 / 3864916437 |
| ISBN-13 | 978-3-86491-643-4 / 9783864916434 |
| Haben Sie eine Frage zum Produkt? |
PDF (Wasserzeichen)Größe: 6,2 MB
DRM: Digitales Wasserzeichen
Dieses eBook enthält ein digitales Wasserzeichen und ist damit für Sie personalisiert. Bei einer missbräuchlichen Weitergabe des eBooks an Dritte ist eine Rückverfolgung an die Quelle möglich.
Dateiformat: PDF (Portable Document Format)
Mit einem festen Seitenlayout eignet sich die PDF besonders für Fachbücher mit Spalten, Tabellen und Abbildungen. Eine PDF kann auf fast allen Geräten angezeigt werden, ist aber für kleine Displays (Smartphone, eReader) nur eingeschränkt geeignet.
Systemvoraussetzungen:
PC/Mac: Mit einem PC oder Mac können Sie dieses eBook lesen. Sie benötigen dafür einen PDF-Viewer - z.B. den Adobe Reader oder Adobe Digital Editions.
eReader: Dieses eBook kann mit (fast) allen eBook-Readern gelesen werden. Mit dem amazon-Kindle ist es aber nicht kompatibel.
Smartphone/Tablet: Egal ob Apple oder Android, dieses eBook können Sie lesen. Sie benötigen dafür einen PDF-Viewer - z.B. die kostenlose Adobe Digital Editions-App.
Zusätzliches Feature: Online Lesen
Dieses eBook können Sie zusätzlich zum Download auch online im Webbrowser lesen.
Buying eBooks from abroad
For tax law reasons we can sell eBooks just within Germany and Switzerland. Regrettably we cannot fulfill eBook-orders from other countries.
aus dem Bereich
