Der Fully Qualified Domain Name (FQDN) ist der vollständige und eindeutige Name eines Computers oder Hosts im Internet oder in einem lokalen Netzwerk. Er besteht aus mehreren Teilen, die eine hierarchische Struktur widerspiegeln.

Aufbau eines FQDN

Ein FQDN setzt sich aus drei Hauptbestandteilen zusammen:

1. Hostname – Der spezifische Name eines Computers oder Dienstes (z. B. www).

2. Domainname – Der Name der übergeordneten Domain (z. B. example).

3. Top-Level-Domain (TLD) – Die oberste Ebene der Domainstruktur (z. B. .com).

Beispiel eines FQDN:
👉 www.example.com.

• www → Hostname

• example → Domainname

• .com → Top-Level-Domain

• Der abschließende Punkt (.) ist optional und steht für die Root-Domain des DNS-Systems.

Warum ist der FQDN wichtig?

✅ Eindeutigkeit: Jeder FQDN ist weltweit einzigartig und verweist auf eine bestimmte Ressource im Internet.
✅ DNS-Auflösung: Er wird von DNS-Servern genutzt, um IP-Adressen für Webseiten und Server zu finden.
✅ SSL-Zertifikate: Ein FQDN wird oft in SSL/TLS-Zertifikaten verwendet, um sichere Verbindungen zu gewährleisten.
✅ E-Mail-Zustellung: Mailserver verwenden FQDNs, um Mails an die richtigen Hosts zu senden.

Unterschied zwischen FQDN und einfacher Domain

• FQDN: mail.google.com (vollständig spezifiziert)

• Einfache Domain: google.com (kann mehrere Hosts enthalten, z. B. www, mail, ftp)

Zusammengefasst ist der FQDN die vollständige Adresse eines Geräts oder Dienstes im Internet, während eine einfache Domain eine allgemeine Adresse ist.

Ein Bearer Token ist eine Art von Zugriffstoken, das zur Authentifizierung und Autorisierung in Webanwendungen und APIs verwendet wird. Der Begriff "Bearer" bedeutet „Inhaber“, was bedeutet, dass jeder, der dieses Token besitzt, Zugriff auf die geschützten Ressourcen hat – ohne zusätzliche Überprüfung.

Merkmale eines Bearer Tokens:

• Selbsttragend: Enthält alle nötigen Informationen zur Authentifizierung.
• Keine zusätzliche Identitätsprüfung: Wer das Token hat, kann es nutzen.
• Wird in HTTP-Headern übertragen: Normalerweise als Authorization: Bearer <token>.
• Oft zeitlich begrenzt: Hat eine Ablaufzeit, um Missbrauch zu reduzieren.
• Wird häufig mit OAuth 2.0 verwendet: Zum Beispiel bei der Authentifizierung mit Drittanbieterdiensten.

Beispiel einer HTTP-Anfrage mit Bearer Token:

GET /geschuetzte-daten HTTP/1.1
Host: api.example.com
Authorization: Bearer abcdef123456

Risiken:

• Kein Schutz bei Diebstahl: Wenn jemand das Token abfängt, kann er sich ausgeben.
• Muss sicher gespeichert werden: Sollte nicht im Client-Code oder in URLs stehen.

💡 Tipp: Um die Sicherheit zu erhöhen, kann man Token mit kurzen Laufzeiten verwenden und sie nur über HTTPS übertragen.

OAuth (Open Authorization) ist ein offenes Standardprotokoll für Autorisierungen, das es Anwendungen ermöglicht, auf Ressourcen eines Nutzers zuzugreifen, ohne dessen Zugangsdaten (z. B. Passwort) direkt zu kennen. Es wird häufig für Single Sign-On (SSO) und API-Zugriffe verwendet.

Wie funktioniert OAuth?

OAuth arbeitet mit Tokens, die einer Anwendung erlauben, im Namen eines Nutzers auf eine Ressource zuzugreifen. Der typische Ablauf sieht so aus:

1. Anfrage auf Autorisierung: Eine Anwendung (Client) möchte auf geschützte Daten eines Nutzers zugreifen (z. B. Facebook-Kontakte).
2. Nutzer-Authentifizierung: Der Nutzer wird zur Anmeldeseite des Anbieters (z. B. Google, Facebook) weitergeleitet und gibt seine Login-Daten ein.
3. Erteilung einer Erlaubnis: Der Nutzer bestätigt, dass die Anwendung auf bestimmte Daten zugreifen darf.
4. Token-Erhalt: Die Anwendung erhält ein Access Token, mit dem sie auf die freigegebenen Daten zugreifen kann.
5. Zugriff auf Ressourcen: Die Anwendung verwendet das Token, um Anfragen an den API-Server zu stellen, ohne das Nutzerpasswort zu kennen.

OAuth 1.0 vs. OAuth 2.0

• OAuth 1.0: Komplexer mit kryptografischer Signatur, aber sicher.
• OAuth 2.0: Einfacher, nutzt HTTPS zur Absicherung, wird heute meist verwendet.

Beispiel-Anwendungen von OAuth

• "Mit Google/Facebook/Apple anmelden"-Buttons
• Drittanbieter-Apps, die auf APIs von Google Drive, Dropbox oder Twitter zugreifen
• Zahlungsdienste wie PayPal, die sich in andere Apps integrieren

Entity-Header sind HTTP-Header, die Informationen über den Hauptteil (Body) einer Nachricht enthalten. Sie können sowohl in Anfragen als auch in Antworten vorkommen und beschreiben Eigenschaften des Inhalts, wie Typ, Länge, Kodierung oder letzte Änderung.

Wichtige Entity-Header:

1. Content-Type

• Gibt den Medientyp (MIME-Typ) des Inhalts an.
• Beispiel:

Content-Type: application/json; charset=UTF-8

2. Content-Length

• Gibt die Größe des Inhalts in Bytes an.
• Beispiel:

Content-Length: 1024

3. Content-Encoding

• Zeigt an, ob der Inhalt komprimiert wurde (z. B. gzip).
• Beispiel:

Content-Encoding: gzip

4. Content-Language

• Gibt die Sprache des Inhalts an.
• Beispiel:

Content-Language: de-DE

5. Cache-Location

• Zeigt die URL oder den Speicherort der eigentlichen Ressource an.
• Beispiel:

Content-Location: /files/document.pdf

6. Last-Modified

• Gibt an, wann der Inhalt zuletzt geändert wurde.
• Beispiel:

Last-Modified: Tue, 30 Jan 2025 14:20:00 GMT

7. ETag

• Eine eindeutige Kennung für eine Version der Ressource, nützlich für Caching.
• Beispiel:

ETag: "abc123xyz"

8. Expires

• Gibt an, wann der Inhalt als veraltet gilt.
• Beispiel:

Expires: Fri, 02 Feb 2025 12:00:00 GMT

9. Allow

• Listet die erlaubten HTTP-Methoden für eine Ressource auf.
• Beispiel:

Allow: GET, POST, HEAD

10. Refresh (Nicht standardisiert, aber oft verwendet)

• Weist den Browser an, die Seite nach einer bestimmten Zeit neu zu laden.
• Beispiel:

Refresh: 10; url=https://example.com

Diese Header helfen dabei, den Inhalt einer HTTP-Nachricht genau zu beschreiben, Caching-Strategien zu optimieren und die korrekte Darstellung sicherzustellen.

Anfrage-Header (Request Headers) sind HTTP-Header, die ein Client (z. B. ein Webbrowser oder eine API-Anfrage) an den Server sendet, um zusätzliche Informationen über die Anfrage, den Client oder die gewünschten Inhalte bereitzustellen.

Wichtige Anfrage-Header:

1. Host

• Gibt die Ziel-Domain oder IP-Adresse des Servers an.
• Beispiel:

Host: www.example.com

2. User-Agent

• Enthält Informationen über den Client, wie Browser-Typ oder Betriebssystem.
• Beispiel:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)

3. Accept

• Definiert, welche Inhaltstypen der Client akzeptieren kann.
• Beispiel:

Accept: text/html, application/json

4. Accept-Language

• Gibt die bevorzugte Sprache des Clients an.
• Beispiel:

Accept-Language: de-DE, en-US

5. Accept-Encoding

• Zeigt an, welche Kompressionsformate der Client unterstützt.
• Beispiel:

Accept-Encoding: gzip, deflate, br

6. Referer

• Gibt die vorherige Seite an, von der der Benutzer gekommen ist.
• Beispiel:

Referer: https://www.google.com/

7. Authorization

• Wird für die Authentifizierung bei geschützten Ressourcen verwendet.
• Beispiel (Basic Auth):

Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ=

8. Cookie

• Enthält Cookies, die der Server zuvor gesetzt hat.
• Beispiel:

Cookie: sessionId=abc123; theme=dark

9. Content-Type (bei POST/PUT-Anfragen)

• Gibt das Datenformat des Anfrageinhalts an.
• Beispiel:

Content-Type: application/json

10. Origin

• Gibt die Ursprungs-URL an und wird oft bei Cross-Origin-Anfragen genutzt.
• Beispiel:

Origin: https://www.example.com

Diese Header helfen dem Server, die Anfrage zu verstehen und entsprechend zu reagieren, indem sie Details über den Client, die bevorzugten Inhalte und Sicherheitsaspekte liefern.

Allgemeine HTTP-Header sind Header, die sowohl in HTTP-Anfragen als auch in HTTP-Antworten verwendet werden können. Sie enthalten allgemeine Informationen zur Verbindung und Datenübertragung, die nicht spezifisch für den Client, den Server oder den Inhalt sind.

Wichtige allgemeine Header:

1. Cache-Control

• Steuert das Caching von Inhalten durch den Client oder Proxy-Server.
• Beispiel:

Cache-Control: no-cache, no-store, must-revalidate

2. Connection

• Definiert, ob die Verbindung nach der Anfrage offen bleiben soll.
• Beispiel:

Connection: keep-alive

3. Date

• Enthält das Datum und die Uhrzeit der HTTP-Nachricht im GMT-Format.
• Beispiel:

Date: Wed, 31 Jan 2025 12:34:56 GMT

4. Pragma (veraltet, aber noch genutzt)

• Ähnlich wie Cache-Control, wird aber hauptsächlich für rückwärtskompatible Caching-Regeln genutzt.
• Beispiel:

Pragma: no-cache

5. Trailer

• Wird verwendet, um anzugeben, welche Header erst nach dem eigentlichen Nachrichten-Body gesendet werden.
• Beispiel:

Trailer: Expires

6. Transfer-Encoding

• Gibt die Art der Übertragung des Nachrichtentextes an, z. B. in Chunks.
• Beispiel:

Transfer-Encoding: chunked

7. Upgrade

• Wird genutzt, um die Verbindung auf ein anderes Protokoll wie WebSockets zu aktualisieren.
• Beispiel:

Upgrade: websocket

8. Via

• Zeigt an, über welche Proxys oder Gateways die Nachricht weitergeleitet wurde.
• Beispiel:

Via: 1.1 proxy.example.com

Diese Header sorgen für eine effizientere Kommunikation zwischen Client und Server, steuern das Caching und ermöglichen Protokoll-Upgrades.

HTTP-Header sind Metadaten, die bei HTTP-Anfragen und -Antworten zwischen Client (z. B. Browser) und Server übertragen werden. Sie enthalten wichtige Informationen zur Kommunikation, wie z. B.:

1. Allgemeine Header – Gelten für Anfragen und Antworten (z. B. Cache-Control zur Steuerung des Caching).
2. Anfrage-Header – Enthalten Details zur Anfrage des Clients (z. B. User-Agent, der den Browser-Typ beschreibt).
3. Antwort-Header – Geben Informationen über die Antwort des Servers (z. B. Server, das den verwendeten Webserver angibt).
4. Entity-Header – Beschreiben den Inhalt der Nachricht (z. B. Content-Type, das den Medientyp der Antwort definiert).

Beispiel einer HTTP-Anfrage mit Headern:

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0
Accept: text/html

Beispiel einer HTTP-Antwort mit Headern:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 3456
Server: Apache

Header werden oft für Sicherheit (z. B. Strict-Transport-Security), Performance (z. B. Cache-Control) und Authentifizierung (z. B. Authorization) genutzt.

Ein Remote Function Call (RFC) ist eine Methode, mit der ein Computerprogramm eine Funktion auf einem entfernten System ausführt, als ob sie lokal auf dem eigenen System aufgerufen würde. RFC wird häufig in verteilten Systemen verwendet, um die Kommunikation und den Datenaustausch zwischen verschiedenen Systemen zu ermöglichen.

Grundprinzipien:

1. Transparenz: Der Aufruf einer Remote-Funktion erfolgt auf die gleiche Weise wie ein lokaler Funktionsaufruf. Der Entwickler muss sich nicht um die Details der Netzwerkkommunikation kümmern.
2. Client-Server-Modell: Das aufrufende System (Client) sendet eine Anfrage an das entfernte System (Server), das die Funktion ausführt und das Ergebnis zurückgibt.
3. Protokolle: RFC basiert auf standardisierten Protokollen, um sicherzustellen, dass Daten korrekt und sicher übertragen werden.

Beispiele:

• SAP RFC: In SAP-Systemen wird RFC verwendet, um zwischen verschiedenen Modulen oder externen Systemen Daten auszutauschen. Es gibt verschiedene Arten wie synchronen RFC (sRFC), asynchronen RFC (aRFC), transactional RFC (tRFC) und queued RFC (qRFC).
• RPC (Remote Procedure Call): RFC ist eine spezifische Implementierung des allgemeineren Konzepts von RPC, das in vielen Technologien wie Java RMI oder XML-RPC verwendet wird.

Anwendungsbereiche:

• Integration von Softwaremodulen über Netzwerke hinweg.
• Echtzeit-Kommunikation zwischen verteilten Systemen.
• Automatisierung und Prozesssteuerung in komplexen Systemlandschaften.

Vorteile:

• Effizienz: Kein direkter Zugriff auf das entfernte System erforderlich.
• Flexibilität: Systeme können unabhängig voneinander entwickelt werden.
• Transparenz: Entwickler müssen die zugrunde liegende Netzwerktechnologie nicht kennen.

Herausforderungen:

• Netzwerkabhängigkeit: Funktioniert nur bei einer stabilen Verbindung.
• Fehlermanagement: Bei Netzwerkausfällen oder Latenzen können Probleme auftreten.
• Sicherheitsrisiken: Daten, die über das Netzwerk gesendet werden, müssen geschützt werden.

Contract Driven Development (CDD) ist eine Softwareentwicklungsmethode, bei der der Schwerpunkt auf der Definition und Verwendung von Contracts (Verträgen) zwischen verschiedenen Komponenten oder Services liegt. Diese Verträge spezifizieren klar, wie verschiedene Softwareteile miteinander interagieren sollen. CDD wird häufig in Microservices-Architekturen oder bei der Entwicklung von APIs verwendet, um sicherzustellen, dass die Kommunikation zwischen unabhängigen Modulen korrekt und konsistent ist.

Wichtige Konzepte von CDD

1. Contracts als Quelle der Wahrheit:

   • Ein Contract ist eine formale Spezifikation (z. B. in JSON oder YAML) eines Dienstes oder einer API, die beschreibt, welche Endpunkte, Parameter, Datenformate und Erwartungen an die Kommunikation bestehen.
   • Der Vertrag wird als zentrale Ressource betrachtet, auf dessen Basis Client- und Server-Komponenten entwickelt werden.

2. Trennung von Implementierung und Vertrag:

   • Die Implementierung eines Services oder einer Komponente muss den spezifizierten Vertrag erfüllen.
   • Die Clients (Nutzer dieses Services) entwickeln ihre Anfragen basierend auf dem Vertrag, unabhängig von der tatsächlichen Implementierung auf der Serverseite.

3. Vertragsgetriebene Tests:

   • Ein zentraler Aspekt von CDD ist das Testen der Einhaltung des Vertrags durch automatisierte Contract Tests. Diese Tests stellen sicher, dass die Interaktion zwischen verschiedenen Komponenten den erwarteten Vorgaben entspricht.
   • Zum Beispiel kann ein Consumer-Driven Contract verwendet werden, um sicherzustellen, dass die vom Verbraucher erwarteten Daten und Formate vom Anbieter geliefert werden.

Vorteile von Contract Driven Development

1. Klare Schnittstellendefinition: Durch die explizite Spezifikation der Verträge wird von Anfang an festgelegt, wie Komponenten miteinander kommunizieren, was Missverständnisse und Fehler minimiert.
2. Unabhängige Entwicklung: Teams, die unterschiedliche Services oder Komponenten entwickeln, können dies parallel tun, solange sie sich an den definierten Vertrag halten.
3. Erleichterte Integration und Tests: Da die Verträge als Basis dienen, können Mock-Server oder -Clients basierend auf diesen Spezifikationen erstellt werden, um Integrationstests durchzuführen, ohne dass alle Komponenten vorhanden sein müssen.
4. Erhöhte Konsistenz und Zuverlässigkeit: Durch automatisierte Contract-Tests wird sichergestellt, dass sich Änderungen in einem Service nicht negativ auf andere Systeme auswirken.

Anwendungsfälle von CDD

• Microservices-Architekturen: In komplexen verteilten Systemen hilft CDD, die Kommunikation zwischen Services zu definieren und zu stabilisieren.
• API-Entwicklung: In der API-Entwicklung stellt ein Contract sicher, dass die angebotene Schnittstelle den Erwartungen der Nutzer (z. B. anderen Teams oder externen Kunden) entspricht.
• Consumer-Driven Contracts: Bei Consumer-Driven Contracts (z. B. durch Tools wie Pact) geben Verbraucher eines Services die erwarteten Interaktionen vor, und die Produzenten stellen sicher, dass ihre Services diesen Erwartungen gerecht werden.

Nachteile und Herausforderungen von CDD

1. Verwaltungsaufwand:
   • Die Pflege und Aktualisierung von Verträgen kann aufwändig sein, insbesondere bei vielen beteiligten Services oder in einer dynamischen Umgebung.
2. Versionierung und Rückwärtskompatibilität:
   • Wenn Verträge sich ändern, müssen sowohl der Anbieter als auch der Verbraucher synchron angepasst werden, was komplexe Abstimmungen erfordert.
3. Überdokumentation:
   • In manchen Fällen kann CDD zu einer zu starken Fokussierung auf Dokumentation führen, was die Flexibilität verringert.

Fazit

Contract Driven Development eignet sich besonders für Projekte mit vielen unabhängigen Komponenten, bei denen klare und stabile Schnittstellen entscheidend sind. Es hilft, Missverständnisse zu vermeiden und stellt durch automatisierte Tests sicher, dass die Kommunikation zwischen Services robust bleibt. Die zusätzliche Komplexität bei der Verwaltung von Verträgen muss jedoch bedacht werden.

RESTful (Representational State Transfer) bezeichnet einen Architekturstil für verteilte Systeme, insbesondere für Webdienste. Es ist eine Methode zur Kommunikation zwischen Client und Server über das HTTP-Protokoll. RESTful Webservices sind APIs, die den Prinzipien des REST-Architekturstils folgen.

Grundprinzipien von REST:

1. Ressourcenbasiertes Modell:

   • Ressourcen werden durch eindeutige URLs (URIs) identifiziert. Eine Ressource kann alles sein, was auf einem Server gespeichert werden kann, wie Datenbankeinträge, Dateien, usw.

2. Verwendung von HTTP-Methoden:

   • RESTful APIs nutzen die HTTP-Methoden, um verschiedene Operationen auf Ressourcen durchzuführen:
     • GET: Zum Abrufen einer Ressource.
     • POST: Zum Erstellen einer neuen Ressource.
     • PUT: Zum Aktualisieren einer bestehenden Ressource.
     • DELETE: Zum Löschen einer Ressource.
     • PATCH: Zum Teilweisen Aktualisieren einer bestehenden Ressource.

3. Zustandslosigkeit (Stateless):

   • Jeder API-Aufruf enthält alle Informationen, die der Server benötigt, um die Anfrage zu verarbeiten. Es wird kein Sitzungszustand auf dem Server zwischen Anfragen gespeichert.

4. Client-Server-Architektur:

   • Eine klare Trennung zwischen Client und Server, wodurch Client und Server unabhängig voneinander entwickelt und skaliert werden können.

5. Cachebarkeit:

   • Antworten sollten als cachebar markiert werden, wenn sie das sind, um die Effizienz zu verbessern und unnötige Anfragen zu reduzieren.

6. Einheitliche Schnittstelle:

   • Eine einheitliche Schnittstelle vereinfacht und entkoppelt die Architektur. Sie basiert auf standardisierten Methoden und Konventionen.

7. Schichtenarchitektur:

   • Eine REST-Architektur kann durch verschiedene Schichten (z. B. Server, Middleware) implementiert werden, die die Komponenten voneinander isolieren und die Skalierbarkeit erhöhen.

Beispiel einer RESTful API:

Angenommen, wir haben eine API für die Verwaltung von "Benutzern" und "Posts" in einer Blogging-Anwendung:

URLs und Ressourcen:

• /users: Sammlung aller Benutzer
• /users/{id}: Einzelner Benutzer mit der ID {id}
• /posts: Sammlung aller Blog-Posts
• /posts/{id}: Einzelner Blog-Post mit der ID {id}

HTTP-Methoden und Operationen:

• GET /users: Ruft eine Liste aller Benutzer ab.
• GET /users/1: Ruft Informationen über den Benutzer mit der ID 1 ab.
• POST /users: Erstellt einen neuen Benutzer.
• PUT /users/1: Aktualisiert die Informationen des Benutzers mit der ID 1.
• DELETE /users/1: Löscht den Benutzer mit der ID 1.

Beispiel-API-Anfragen:

• GET-Anfrage:

GET /users/1 HTTP/1.1
Host: api.example.com

Antwort:

{
  "id": 1,
  "name": "John Doe",
  "email": "john.doe@example.com"
}

POST-Anfrage:

POST /users HTTP/1.1
Host: api.example.com
Content-Type: application/json

{
  "name": "Jane Smith",
  "email": "jane.smith@example.com"
}

Antwort:

HTTP/1.1 201 Created
Location: /users/2

Vorteile von RESTful APIs:

• Einfachheit: Durch die Nutzung von HTTP und standardisierten Methoden sind RESTful APIs einfach zu verstehen und zu implementieren.
• Skalierbarkeit: Aufgrund der Zustandslosigkeit und der Schichtenarchitektur können RESTful Systeme leicht skaliert werden.
• Flexibilität: Die Trennung von Client und Server ermöglicht eine unabhängige Entwicklung und Bereitstellung.

RESTful APIs sind eine weit verbreitete Methode zur Erstellung von Webdiensten und bieten eine einfache, skalierbare und flexible Architektur für die Kommunikation zwischen Client und Server.