REST - Versionsgeschichte

37.49.72.8: /* Wichtige Begriffe */

2019-10-19T10:26:35Z

Wichtige Begriffe

37.49.72.8 am 19. Oktober 2019 um 10:24 Uhr

2019-10-19T10:24:43Z

37.49.72.8: /* Layered System */

2019-10-19T10:06:43Z

Layered System

37.49.72.8: Die Seite wurde neu angelegt: „== Links == https://medium.com/extend/what-is-rest-a-simple-explanation-for-beginners-part-1-introduction-b4a072f8740f https://www.cloudcomputing-insider.de/…“

2019-10-19T10:06:27Z

Die Seite wurde neu angelegt: „== Links == https://medium.com/extend/what-is-rest-a-simple-explanation-for-beginners-part-1-introduction-b4a072f8740f https://www.cloudcomputing-insider.de/…“

Neue Seite

== Links ==
https://medium.com/extend/what-is-rest-a-simple-explanation-for-beginners-part-1-introduction-b4a072f8740f
https://www.cloudcomputing-insider.de/was-ist-eine-rest-api-a-611116/

== Allgemeines ==
REST = REpresentational State Transfer
API für Application Programming Interface

* REST ist ein Ansatz für die Client Server Kommunikation im Netz und funktioniert prinzipiell ähnlich wie das Ausliefern von Webseiten.
* REST APIs sind nützlich in verteilten IT-Systemen.
* REST ist KEIN Protokoll und auch kein Standard sondern eher ein Prinzip oder Design Pattern für Schnittstellen. Erfüllt ein Service mit seiner Schnittstelle dieses Muster spricht man von einer RESTful API.
* REST nutzt aber Standard-Protokolle und Datenstandards wir HTTP/S, UärI, JSON, XML

== Ursprung ==
* Von Roy Fielding als Konzept parallel zu HTTP 1.1 entwickelt.
* 2000 in seiner Dissertation „Architectural Styles and the Design of Network-based Software Architectures“ vorgestellt.
* WorldWideWeb und Browser bieten daher schon fast alles was man braucht. Statische Webseiten werden z.B. nach dem REST Prinzip ausgeliefert.
* Für Programme nutzt man oft JSON oder XML als Format und nicht HTML da diese besser maschinell verarbeitet werden können.

== Wichtige Begriffe ==
TODO

Client — the client is the person or software who uses the API. It can be a developer, for example you, as a developer, can use Twitter API to read and write data from Twitter, create a new tweet and do more actions in a program that you write. Your program will call Twitter’s API. The client can also be a web browser. When you go to Twitter website, your browser is the client who calls Twitter API and uses the returned data to render information on the screen.

Resource — a resource can be any object the API can provide information about. In Instagram’s API, for example, a resource can be a user, a photo, a hashtag. Each resource has a unique identifier. The identifier can be a name or a number.

== Prinzipien ==
REST gibt nicht vor wie ein Service im Detail implementiert oder Programmiert wird. Vielmehr gibt es '''sechs Architekturprinzipien (Constraints)'''.

=== Client-Server-Modell ===
REST verlangt ein Client-Server-Modell. D.h. Daten und Nutzerinterface sind getrennt. Der Server liefert die Daten an den Client.

Vorteile: Clients einfach auf verschiedenen Plattformen einzurichten. Server einfacher skalierbar.

=== Zustandslosigkeit (stateless)===
Client und Server kommunizieren zustandslos („stateless“). D.h. der Client schickt bei jeder Anfrage alle Informationen die der Server benötigt. Der Server muss sich nichts "merken".

Vorteil: Zuverlässigkeit, Einheitlichkeit, Skalierbarkeit.
Nachteil: mehr Overhead bei der Netzwerkkommunikation (weniger Performance)

===Caching===
Clients dürfen vom Server gesendete Antworten auch speichern und wiederverwenden. Der Server kennzeichnet Informationen müssen als „cacheable“ oder „non-cacheable“.

Vorteile: Höhere Effizienz durch weniger Traffic und dadurch leichter skalierbar.
Nachteile: Risiko dass der Client veraltete Daten aus dem Cache nutzt.

=== Einheitliche Schnittstelle ===
Die Schnittstelle ist einheitlich und von der Art des Dienstes unabhängig.

Vorteil: Einfache Architektur mit erhöhter Visibilität von Interaktionen.
Nachteil: U.u. leidet die Effihienz als bei auf die Anwendung spezialisierten Lösungen. Alle Informationen müssen in ein standardisiertes Format gebracht werden.

=== Layered System ===
Es gibt mehrere, hierarchisch Angelegte Schichte. Jede Schicht (Layer) hat bestimmte Aufgaben. Jeder Layer interagiert nur mit den direkt angrenzende Schichten.
Die Layer können für verschiedene Aufgaben eingesetzt werden. Z.B. Security Layer, Load Balancer, Caching. Die eigentliche Information wird unverändert weitergegeben.

Vorteile: Zusätzliche Funktionalität entkoppelt (gekapselt) von der eigentlichen Kommunikation, Skalierbarkeit
Nachteil größerer Overhead, größerer Latenz mit jeder Schicht.

=== Code-On-Demand ===
Dies ist keine Bedingung sondern eine Option. REST erlaubt dass der Client Programmteile nachladen kann. Z.B. über Skripte oder Applets. Dies kann aber als Bedingung auch ausgeschlossen oder deaktiviert werden.

== Praxis ==
Für Restserverices nutzt man in der Praxis i.d.R. das HTTP oder HTTPS Protokoll. Also das gleiche das für das Ausliefern von Webseiten zuständig ist. Der Client (z.B. ein Webbrowser) fordert eine URL/URI auf und bekommt vom Server eine Antwort.

HTTP Methoden geben an, welche Operation der Service ausführen soll:

GET | POST | PATCH | DELETE

=== Ausprobieren ===
http://jsonplaceholder.typicode.com/ verfügbare Fake Online REST API for Testing and Prototyping.

Der Service von jsonplaceholder kann eine Menge von zusammenhängenden Datensätzen liefern. Dazu gehören Posts, Kommentare, Fotos, Alben, Todo-Listen, Nutzer... Die Methoden die man nutzen kann sind:
GET - fordert Daten vom Server an
POST - übermittelt Daten an den Server
PUT/PATCH - ändern bestehende Daten auf dem Server
DELETE - löscht bestehende Daten auf dem Server

Aufrufe die Daten verändern (DELETE / PUT) werden dabei vom Server nicht ausgeführt aber angenommen. So kann man testen wie man möchte.

@@ Zeile 27: / Zeile 27: @@
 '''Client''' — Der Client nutzt die API. Oft ist das eine Person die am Browser sitzt und eine Webseite anfordert. Du könntest auch ein Client Skript schreiben, das die Twitter API nutzt um Post zu holen oder zu schreiben. Dein Programm wäre ei Client das den RESTful Service von Twitter nutzt.
-'''Resource''' — eine Resource ist ein Objekt für das die API Informationen liefern kann. In Instagram wäre das z.B. ein User, ein Photo oder ein Hashtag. Jede Resource hat eine eindeutige Bezeichung denn Identifier. Z.B. eine Zahl oder ein Name. Wichtig ist die Eindeutigkeit.
+'''Resource''' — eine Resource ist das was der Client anfordert. Oder allgemeiner, ein Objekt über welches die API Informationen liefern kann. In Instagram wäre das z.B. ein User, ein Photo oder ein Hashtag. Jede Resource hat eine eindeutige Bezeichung denn Identifier. Z.B. eine Zahl oder ein Name. Wichtig ist die Eindeutigkeit. Eine Resource hat bestimmte Eigenschaften über welche die API Auskunft geben kann. Z.B. den Namen eines Users.
 == Prinzipien ==

@@ Zeile 2: / Zeile 2: @@
   https://medium.com/extend/what-is-rest-a-simple-explanation-for-beginners-part-1-introduction-b4a072f8740f
   https://www.cloudcomputing-insider.de/was-ist-eine-rest-api-a-611116/
 == Allgemeines ==
   REST = REpresentational State Transfer
   API für Application Programming Interface
 * REST ist ein Ansatz für die Client Server Kommunikation im Netz und funktioniert prinzipiell ähnlich wie das Ausliefern von Webseiten.
@@ Zeile 21: / Zeile 25: @@
 == Wichtige Begriffe ==
-TODO
+'''Client''' — Der Client nutzt die API. Oft ist das eine Person die am Browser sitzt und eine Webseite anfordert. Du könntest auch ein Client Skript schreiben, das die Twitter API nutzt um Post zu holen oder zu schreiben. Dein Programm wäre ei Client das den RESTful Service von Twitter nutzt.
-Resource — a resource can be any object the API can provide information about. In Instagram’s API, for example, a resource can be a user, a photo, a hashtag. Each resource has a unique identifier. The identifier can be a name or a number.
+'''Resource''' — eine Resource ist ein Objekt für das die API Informationen liefern kann. In Instagram wäre das z.B. ein User, ein Photo oder ein Hashtag. Jede Resource hat eine eindeutige Bezeichung denn Identifier. Z.B. eine Zahl oder ein Name. Wichtig ist die Eindeutigkeit.
 == Prinzipien ==
@@ Zeile 79: / Zeile 81: @@
   DELETE - löscht bestehende Daten auf dem Server
-Aufrufe die Daten verändern (DELETE / PUT) werden dabei vom Server nicht ausgeführt aber angenommen. So kann man testen wie man möchte.
+Aufrufe die Daten verändern (DELETE / PUT) werden dabei vom Server nicht ausgeführt aber angenommen. So kann man testen wie man möchte. Folgender Aufruf:

@@ Zeile 57: / Zeile 57: @@
 Die Layer können für verschiedene Aufgaben eingesetzt werden. Z.B. Security Layer, Load Balancer, Caching. Die eigentliche Information wird unverändert weitergegeben.
-Vorteile: Zusätzliche Funktionalität entkoppelt (gekapselt) von der eigentlichen Kommunikation, Skalierbarkeit
+ Vorteile: Zusätzliche Funktionalität entkoppelt (gekapselt) von der eigentlichen Kommunikation, Skalierbarkeit
-Nachteil größerer Overhead, größerer Latenz mit jeder Schicht.
+ Nachteil größerer Overhead, größerer Latenz mit jeder Schicht.
 === Code-On-Demand ===