REST
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.
