Bearbeiten von „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.