Betriebs- und Datensysteme
Topic outline
-
Definition zentraler Begriffe,
Geschichte und Entwicklung, Aufgaben von Betriebssystemen-
Video zu den Lernzielen der Unit 01, Dauer 00:30
-
Lerninhalte Unit 01
1.1 Einführung - Historischer Hintergrund und Motivation
1.2 Generationen von Betriebssystemen
1.3 Grundbegriffe
1.4 GrundaufgabenLerninhalte Unit 01
-
„Die Notwendigkeit ist die Mutter der Erfindung“ Sprichwort
-
Zeitliche Abfolge von Betriebssystemen
-
-
-
-
-
-
-
Microsoft Windows verwendet zwei große Dateisysteme:
▪ FAT, das vom alten DOS geerbt wurde und als spätere Erweiterung exFAT hat.
▪ NTFS, das Format, das die meisten modernen Versionen dieses Betriebssystems standardmäßig verwenden.
ReFS wurde von Microsoft auch als Format der neuen Generation für Server-Computer ab Windows Server 2012 eingeführt -
Open-Source-Linux zielt darauf ab, verschiedene Arten von Dateisystemen zu implementieren, zu testen und zu verwenden.
-
-
In Linux und auch in Unix werden eine Vielzahl verschiedener Schnittstellen verwendet.
-
-
8.1.2 Server-Client API
PHP Datenbank API
8.1.3 REST API
REST steht für REpresentational State Transfer. REST ist ein Software-Architekturstil, der eine Reihe von Regeln für die Erstellung von Webdiensten definiert. Webdienste, die dem REST-Architekturstil folgen, werden als RESTful Webdienste bezeichnet. Sie ermöglichen es anfragenden Systemen, auf Webressourcen zuzugreifen und diese zu bearbeiten, indem sie einen einheitlichen und vordefinierten Satz von Regeln verwenden. Die Interaktion in REST-basierten Systemen erfolgt über das Hypertext Transfer Protocol (HTTP) des Internets.
REST stellt damit eine Form von Client-Server API dar. Allerding ist REST auf bestimmte architektonische Merkmale eingeschränkt.
▪ Einheitliche Schnittstelle
▪ Zustandslos
▪ Zwischenspeicherfähig
▪ Client-Server
▪ Mehrschichtiges System
▪ Code auf Abruf
Die einzelnen Merkmale bedeuten im Detail:
Einheitliche Schnittstelle: Dies ist eine wichtige Voraussetzung für die Unterscheidung zwischen einer REST-API und einer Nicht-REST-API. Sie besagt, dass es eine einheitliche Art der Interaktion mit einem bestimmten Server geben sollte, unabhängig vom Gerät oder der Art der Anwendung (Website, mobile App).
Es gibt vier Richtlinien, die das Prinzip der einheitlichen Schnittstelle darstellen:
▪ Ressourcenbasiert: Einzelne Ressourcen werden in Anfragen identifiziert.
Zum Beispiel: API/Benutzer.
▪ Manipulation von Ressourcen durch Repräsentationen: Der Client verfügt über eine Repräsentation der Ressource, die genügend Informationen enthält, um die Ressource auf dem Server zu ändern oder zu löschen, sofern er dazu berechtigt ist.
Beispiel: Normalerweise erhält ein Benutzer eine Benutzerkennung, wenn er eine Benutzerliste anfordert, und verwendet dann diese Kennung, um diesen bestimmten Benutzer zu löschen oder zu ändern.
▪ Selbstbeschreibende Nachrichten: Jede Nachricht enthält genügend Informationen, um zu beschreiben, wie die Nachricht zu verarbeiten ist, so dass der Server die Anfrage leicht analysieren kann.
▪ Hypermedia als Motor des Anwendungsstatus (HATEOAS): Sie muss für jede Antwort Links enthalten, damit der Client andere Ressourcen leicht finden kann.
Zustandslos bedeutet, dass der für die Bearbeitung der Anfrage erforderliche Zustand in der Anfrage selbst enthalten ist und der Server nichts im Zusammenhang mit der Sitzung speichert. Bei REST muss der Client alle Informationen angeben, damit der Server die Anfrage erfüllen kann, sei es als Teil von Abfrageparametern, Headern oder URI. Die Zustandslosigkeit ermöglicht eine höhere Verfügbarkeit, da der Server den Sitzungszustand nicht pflegen, aktualisieren oder übermitteln muss. Ein Nachteil besteht darin, dass der Client viele Daten an den Server senden muss, was die Möglichkeiten der Netzwerkoptimierung einschränkt und mehr Bandbreite erfordert.
Cachefähig: Bei jeder Antwort sollte angegeben werden, ob die Antwort zwischengespeichert werden kann und wie lange die Antwort auf der Client-Seite zwischengespeichert werden kann. Der Client wird die Daten aus seinem Zwischenspeicher für jede nachfolgende Anfrage zurückgeben und es wäre nicht notwendig, die Anfrage erneut an den Server zu senden. Eine gut verwaltete Zwischenspeicherung macht einige Client-Server-Interaktionen teilweise oder ganz überflüssig, was die Verfügbarkeit und Leistung weiter verbessert. Allerdings kann es vorkommen, dass der Benutzer veraltete Daten erhält.
Client-Server: REST-Anwendungen sollten eine Client-Server-Architektur haben. Ein Client ist jemand, der Ressourcen anfordert und sich nicht um die Datenspeicherung kümmert, die intern auf jedem Server verbleibt, und ein Server ist jemand, der die Ressourcen hält und sich nicht um die Benutzeroberfläche oder den Benutzerzustand kümmert. Sie können sich unabhängig voneinander weiterentwickeln. Der Client muss nichts über die Geschäftslogik wissen, und der Server muss nichts über die Benutzeroberfläche des Frontend wissen.
Mehrschichtiges System: Eine Anwendungsarchitektur muss aus mehreren Schichten aufgebaut sein. Jede Schicht weiß nichts über eine andere Schicht als die der unmittelbaren Schicht, und es kann viele Zwischenserver zwischen dem Client und dem Endserver geben. Zwischenserver können die Systemverfügbarkeit verbessern, indem sie einen Lastausgleich ermöglichen und gemeinsame Caches bereitstellen.
Code auf Anfrage: Dies ist eine optionale Funktion. Demnach können die Server dem Client auch ausführbaren Code zur Verfügung stellen. Zu den Beispielen für Code on Demand gehören kompilierte Komponenten wie Java Servlets und serverseitige Skripte wie JavaScript.
Regeln der REST-API: Es gibt bestimmte Regeln, die bei der Erstellung von REST-API-Endpunkten beachtet werden sollten.
REST basiert auf der Ressource oder dem Substantiv und nicht auf der Aktion oder dem Verb. Das bedeutet, dass ein URI einer REST-API immer mit einem Substantiv enden sollte. Beispiel: /api/users ist ein gutes Beispiel, aber /api?type=users ist ein schlechtes Beispiel für die Erstellung einer REST-API.
HTTP-Verben werden verwendet, um die Aktion zu identifizieren. Einige der HTTP-Verben sind - GET, PUT, POST, DELETE, GET, PATCH.
Eine Webanwendung sollte in Ressourcen wie Benutzer organisiert sein und dann HTTP-Verben wie GET, PUT, POST, DELETE verwenden, um diese Ressourcen zu ändern. Und als Entwickler sollte es klar sein, was getan werden muss, wenn man sich den Endpunkt und die verwendete HTTP-Methode ansieht.
Beispiele für REST:
Abbildung 8‑3: Nutzen der REST API eines Dienstes zur Auflösung von IP Adressen
Das Beispiel zeigt einen Python-Quellcode. Der Dienst ipapi.co bietet ein öffentliches REST-API, um den Standort einer IP-Adresse zu ermitteln. Der Endpunkt der Schnittstelle gibt die vollständigen Standortinformationen für eine in der URL angegebene IP-Adresse zurück.
Der HTTP Request ist in der Form GET https://ipapi.co/{ip}/{format}/ mit den URL-Parametern der Adresse und dem Rückgabeformat zu senden. Die Antwort des Servers kann in json, jsonp, xml, csv oder yaml angefordert werden.
API in Python
https://ipapi.co/api/
https://ipapi.co/api/#complete-location
8.1.4 Erstellen einer REST-Anwendung
Zur Bereitstellung eines REST API genügt die Rückgabe der Ergebnisse in einem definierten Format. Natürlich muss die Dokumentation des API die möglichen Formate bekanntgeben. Er sollten nach Möglichkeit übliche Datenformate sein.
Der beispielhafte Quellcode in PHP fordert ein Preisinformation im JSON-Format an.
<?php
header("Content-Type:application/json");
if(!empty($_GET['name']))
{
$name=$_GET['name'];
$price = get_price($name);
if(empty($price))
{ response(200,"Product Not Found",NULL); }
else
{ response(200,"Product Found",$price); }
} else { response(400,"Invalid Request",NULL);}
function response($status,$status_message,$data)
{
header("HTTP/1.1 ".$status);
$response['status']=$status;
$response['status_message']=$status_message;
$response['data']=$data;
$json_response = json_encode($response);
echo $json_response;
}
function get_price($name)
{
$products = [ "book"=>20, "pen"=>10, "pencil"=>5];
foreach($products as $product=>$price)
{
if($product==$name)
{ return $price;
break;
}
}
}
?>
JSON (JavaScript Object Notation) ist ein schlankes Datenaustauschformat,
das für Menschen einfach zu lesen und zu schreiben und für Maschinen einfach zu parsen (Analysieren von Datenstrukturen) und zu generieren ist. Es basiert auf einer Untermenge der JavaScript Programmiersprache, Standard ECMA-262 dritte Edition - Dezember 1999.
Abbildung 8‑4: JSON-Syntax-Diagramm (Quelle:1.https://www.json.org/json-de.html)
-