Kurze Zeitreise

Die Geschichte von HTTP beginnt 1989 mit Tim Berners-Lee, einem Physiker am CERN. Er entwickelte das HTTP-Protokoll, um die Übertragung von HTML-Dokumenten, den sogenannten Hypertexten, über das Internet zu ermöglichen. Dies war ein Schlüsselbestandteil seiner Vision vom World Wide Web, einem Informationsmanagement-System, dass es Benutzern ermöglicht, Informationen über das Internet zu teilen und zu verlinken.

Die Veröffentlichung der ersten dokumentierten Version von HTTP, HTTP/0.9, erfolgte 1991. Es war ein sehr einfaches Protokoll, die lediglich die GET-Methode unterstützte. Dies erlaubte einem Webbrowser, eine Anfrage an einen Webserver zu senden und ein HTML-Dokument zurückzuerhalten.

Die Veröffentlichung von HTTP/1.0 erfolgte 1996 als IETF RFC 1945. Es fügte weitere Methoden wie POST und HEAD hinzu und unterstützte auch HTTP-Header, was zusätzliche Metainformationen über die Anfrage und die Antwort ermöglichte.

HTTP/1.1, das heute weit verbreitet ist, kam 1997 zum Einsatz und man hat es später in RFC 2616 festgelegt. Es fügte wichtige Verbesserungen wie Persistente Verbindungen, Chunked-Übertragungen und zusätzliche Cache-Steuerung hinzu.

HTTP/2, im Jahr 2015, mit dem Ziel, die Leistung zu verbessern und die Latenz zu reduzieren. Es unterstützt Multiplexing, Priorisierung und Kompression von HTTP-Headern.

HTTPS – Hypertext Transfer Protocol Secure

Eingeführt, um die Übertragung sensibler Daten über das Internet sicherer zu machen. Es verwendet eine Verschlüsselung, um die Daten vor der Abhörung und Manipulation zu schützen.

Die Geschichte von HTTPS beginnt 1994 mit Netscape Communications, dem Unternehmen hinter dem damals populären Netscape Navigator Webbrowser. Sie führten HTTPS ein, zusammen mit dem SSL (Secure Sockets Layer) Protokoll, um sichere Transaktionen über das Web zu ermöglichen.

Das SSL-Protokoll entwickelte sich über die Jahre weiter und es fand schließlich eine Ersetzung durch das TLS (Transport Layer Security) Protokoll statt, dass man heute für HTTPS verwendet. Die aktuelle Version (Stand Juli 2023) ist TLS 1.3, dessen Veröffentlichung im Jahr 2018 stattfand.

Heute wird HTTPS von fast allen Websites verwendet, die sensible Daten übertragen, wie Online-Banking, E-Commerce und E-Mail-Dienste. Mit der Einführung von Let’s Encrypt, einer kostenlosen, automatisierten und offenen Zertifizierungsstelle, ist HTTPS auch zunehmend auf anderen Websites verbreitet, was zu einem sichereren Web für alle beiträgt. Auch Google achtet auf das Protokoll, wenn man beabsichtigt, das Ranking der Website auf Dauer zu verbessern.

Auch wenn es über die Geschichte ersichtlich ist, wofür unsere beiden Kandidaten gut sind, gehe ich nachfolgend nochmals etwas spezifischer auf die Definitionen, sowie auf die Vor- und Nachteile ein.

HTTP: Was ist das?

HTTP steht für Hypertext Transfer Protocol. Es ist ein Protokoll, das für die Übertragung von Informationen im World Wide Web verwendet wird. HTTP ist zustandslos, das bedeutet, dass jede Anfrage, die über HTTP gesendet wird, unabhängig von den vorherigen Anfragen ist.

HTTPS: Was ist das?

HTTPS steht für Hypertext Transfer Protocol Secure. Wie der Name schon sagt, ist es eine sichere Version von HTTP. Es verwendet SSL (Secure Sockets Layer) oder TLS (Transport Layer Security) Protokolle, um eine verschlüsselte Verbindung zwischen dem Client (zum Beispiel einem Webbrowser) und dem Server herzustellen. Dies bedeutet, dass alle Daten, die zwischen Client und Server übertragen werden, verschlüsselt und daher sicher sind.

Unterschiede zwischen den beiden Protokollen

Der Hauptunterschied zwischen HTTP und HTTPS ist die Sicherheit. HTTP überträgt Daten in Klartext. Das bedeutet, wenn jemand die Daten während der Übertragung abfangen kann, kann er sie leicht lesen und verstehen. HTTPS dagegen verschlüsselt die Daten, die übertragen werden. Das bedeutet, selbst wenn jemand die Daten abfängt, kann er sie nicht lesen, ohne den richtigen Schlüssel zu haben, um die Verschlüsselung zu entschlüsseln.

Ein weiterer Unterschied ist die Port-Nummer, die von den beiden Protokollen verwendet wird. HTTP verwendet Port 80, während HTTPS Port 443 verwendet.

Vorteile von HTTP

Einfachheit: HTTP ist einfacher zu implementieren, da es keine Zertifikate oder Schlüssel benötigt.

Geschwindigkeit: Da es keine Verschlüsselung gibt, ist HTTP in der Regel schneller als HTTPS.

Nachteile von HTTP

Sicherheit: HTTP ist unsicher. Jede übertragene Information, einschließlich sensibler Daten wie Kreditkartennummern und Passwörtern, kann abgefangen und gelesen werden.

Vorteile von HTTPS

Sicherheit: HTTPS ist sicher. Es schützt die übertragenen Daten vor Abhören und Manipulation.

Vertrauen: Websites, die es verwenden, sind in der Regel von Benutzern und Suchmaschinen als vertrauenswürdiger eingestuft.

SEO: Suchmaschinen wie Google bevorzugen HTTPS-Websites und ordnen sie in den Suchergebnissen höher ein.

Nachteile von HTTPS

Komplexität: Die Einrichtung von HTTPS erfordert den Kauf und die Installation eines SSL-Zertifikats. Dies kann für einige Benutzer kompliziert sein.

Leistung: Aufgrund der Verschlüsselung kann es etwas langsamer sein als HTTP.

Fazit

Die Nutzung der beiden Protokolle hängt stark von den Anforderungen und dem Schutzbedarf von Nutzerdaten ab. HTTP, obwohl weniger komplex und in manchen Fällen schneller, bietet keine Sicherheit für übertragene Daten. Jede Information, die über HTTP gesendet wird, ist anfällig für das Abfangen und den Missbrauch.

HTTPS hingegen stellt sicher, dass alle übertragenen Daten verschlüsselt und somit sicher sind. Es bietet ein höheres Maß an Vertrauen für Benutzer und kann sogar die SEO-Positionierung verbessern. Obwohl die Einrichtung der sichereren Variante eine gewisse Komplexität mit sich bringt und die Performance potenziell etwas beeinträchtigt werden kann, sind die Sicherheits- und Vertrauensvorteile in der heutigen digitalen Landschaft unverzichtbar. Aus diesem Grund fällt einem auch immer wieder das Schlosssymbol in der URL Leiste auf, die auf eine ungeschützte oder eben geschützte Website hinweist.

Insgesamt ist es klar, dass der Wechsel zu HTTPS nicht nur für Websites, die sensible Informationen verarbeiten, sondern für alle Websites von Vorteil ist. Dieser Trend zur Universalverschlüsselung ist ein positiver Schritt in Richtung eines sichereren und vertrauenswürdigeren Internets für alle Benutzer und ist in Bezug auf das Kosten-Nutzen-Verhältnis innerhalb eines vertretbaren Rahmens.

Der Beitrag http und https – Eine Reise zur Web-Sicherheit erschien zuerst auf CEOsBay.

Kurze Zeitreise

Wie bereits zu Beginn erwähnt, geht die Entstehung von OpenAPI auf die Einführung der Swagger-Spezifikation zurück, die ursprünglich Tony Tam im Jahr 2010 entwickelt hat. Swagger entstand aus dem Bedürfnis heraus, eine standardisierte und einfache Möglichkeit zur Beschreibung, Dokumentation und Interaktion mit RESTful-APIs zu schaffen. Die Spezifikation und die damit verbundenen Tools gewannen schnell an Popularität in der Entwicklergemeinschaft.

Im Jahr 2015 wurde die OpenAPI-Initiative (OAI) ins Leben gerufen, um die Weiterentwicklung der Swagger-Spezifikation in einer kollaborativen und branchenübergreifenden Umgebung voranzutreiben. Die OAI wurde von Unternehmen wie Google, IBM, Microsoft, SmartBear Software und weiteren Technologieunternehmen unterstützt.

In der Folge hat die Swagger-Spezifikation unter der Leitung der OpenAPI-Initiative eine Weiterentwicklung erfahren den neuen Namen OpenAPI erhalten. Dies trug dazu bei, die gemeinschaftliche Natur des Projekts widerzuspiegeln. Die Veröffentlichung der ersten Version der OpenAPI-Spezifikation (OpenAPI 2.0) fand im September 2016 statt und basierte auf der damaligen Swagger 2.0-Spezifikation.

Seitdem hat es sich als Standard für die Beschreibung von RESTful-APIs etabliert und ist durch kontinuierliche Weiterentwicklung und Zusammenarbeit in der Industrie gewachsen. Die neueren Versionen brachten eine Reihe von Verbesserungen und neue Funktionen im Vergleich zu OpenAPI 2.0. Darunter eine bessere Unterstützung für JSON-Schema, verbesserte Modularität und erweiterte Möglichkeiten zur Beschreibung von API-Endpunkten sowie Datenmodellen.

Wie funktioniert OpenAPI?

Grundlagen

OpenAPI definiert eine standardisierte, sprachagnostische Schnittstelle, um RESTful-APIs auf eine maschinenlesbare Weise zu beschreiben. Diese Beschreibung enthält Informationen über die verfügbaren Endpunkte, die unterstützten Operationen (wie GET, POST, PUT, DELETE) (Siehe auch CRUD), die möglichen Rückgabewerte und viele weitere Details. Es verwendet das YAML- oder JSON-Format, um diese Beschreibungen auf leicht verständliche und bearbeitbare Weise zu präsentieren.

Vorteile

Standardisierung:

Es bietet eine einheitliche und standardisierte Methode zur Beschreibung von RESTful-APIs. Dadurch gewährleistet bzw. verbessert man die Interoperabilität zwischen verschiedenen Systemen und Technologien.

Dokumentation:

OpenAPI-Dokumente dienen als lebendige Dokumentation der API, die immer auf dem neuesten Stand ist. Dies erleichtert die Zusammenarbeit zwischen verschiedenen Teams und reduziert die Wahrscheinlichkeit von Fehlern und Inkonsistenzen.

Generierung von Code und Client-Bibliotheken:

Durch die maschinenlesbare Natur der Spezifikation können Entwickler automatisch Code-Stubs, Server-Implementierungen und Client-Bibliotheken in verschiedenen Programmiersprachen generieren.

API-Design und -Validierung:

Es ermöglicht Entwicklern, ihre API-Designs frühzeitig zu validieren und Inkonsistenzen zu identifizieren, bevor sie in die Implementierung einfließen.

Interaktive API-Explorer:

Man kann OpenAPI-Dokumente in interaktive API-Explorer, wie z. B. Swagger UI, importieren, um APIs auf benutzerfreundliche Weise zu erkunden und zu testen.

Ökosystem

Das Ökosystem umfasst zahlreiche Tools und Lösungen, die Entwickler bei der Arbeit mit der Spezifikation unterstützen. Einige der bekanntesten Tools sind:

Swagger:

Swagger ist eine Sammlung von Tools, die Entwicklern helfen, ihre APIs zu entwerfen, zu dokumentieren und zu testen. Dazu gehören unter anderem Swagger Editor, Swagger Codegen und Swagger UI.

ReDoc:

ReDoc ist eine Open-Source-Lösung zur Erstellung von API-Dokumentationen auf Basis von OpenAPI-Dokumenten. Es bietet eine übersichtliche und ansprechende Darstellung der API-Dokumentation, die für Endbenutzer leicht zugänglich ist.

Postman:

Postman ist ein weit verbreitetes API-Entwicklungstool, das die Unterstützung für OpenAPI-Spezifikationen bietet. Es ermöglicht Entwicklern, APIs zu entwerfen, zu testen, zu dokumentieren und zu überwachen, indem sie die OpenAPI-Dokumente importieren und mit den integrierten Tools interagieren.

API-Lebenszyklus

Der Einsatz von OpenAPI erstreckt sich über den gesamten API-Lebenszyklus:

Planung:

Entwickler können OpenAPI verwenden, um das API-Design zu skizzieren und Einigkeit über die Funktionsweise und Struktur der API zu erzielen.

Entwicklung:

Mit automatisch generierten Code-Stubs und Client-Bibliotheken auf Basis der Spezifikation können Entwickler schnell und effizient an der Implementierung arbeiten.

Testen:

Es ermöglicht das einfache Erstellen von Testfällen und das automatisierte Testen von APIs auf Kompatibilität und Konformität mit der Spezifikation.

Dokumentation:

Die lebendige Dokumentation auf Grundlage von OpenAPI-Dokumenten stellt sicher, dass API-Benutzer immer auf dem neuesten Stand der API-Funktionalität sind.

Deployment:

Man kann OpenAPI-Dokumente für die automatische Bereitstellung und Konfiguration von APIs auf verschiedenen Plattformen und Umgebungen verwenden.

Überwachung und Wartung:

Damit generierte Tests und Überwachungstools kann man die API-Performance überwachen und Wartungsmaßnahmen effizient durchgeführen.

Alternative API-Spezifikationen

Daneben gibt es noch andere API-Spezifikationen wie RAML (RESTful API Modeling Language) und API Blueprint. Alle drei Spezifikationen haben ähnliche Zielsetzungen, unterscheiden sich jedoch in Syntax, Tool-Unterstützung und Popularität. OpenAPI ist derzeit die am weitesten verbreitete Spezifikation und eine Vielzahl von Organisationen sowie Entwickler bevorzugen es.

Fazit:

OpenAPI ist eine leistungsstarke und flexible Spezifikation, die Entwicklern hilft, RESTful-APIs zu entwerfen, zu erstellen und zu dokumentieren. Es bietet eine standardisierte, sprachunabhängige Schnittstelle und unterstützt den gesamten API-Lebenszyklus von der Planung bis zur Überwachung. Mit einem reichhaltigen Ökosystem an Tools und Lösungen hat es seine Stellung als führende API-Spezifikation im heutigen schnelllebigen Technologieumfeld gefestigt.

Der Beitrag OpenAPI – Die Brücke für nahtlose Kommunikation und effiziente Integration von Web-Services erschien zuerst auf CEOsBay.

Kurze Zeitreise

Die Entstehung von Content-Management-Systemen (CMS) ist eng mit der Entwicklung des Internets und dem Bedarf an benutzerfreundlichen Lösungen zur Erstellung und Verwaltung von Webinhalten verbunden.

In den frühen 90ern bzw. in den Anfängen des Internets, haben hauptsächlich Webentwickler Websites erstellt, die HTML, CSS, JavaScript und andere Programmiersprachen beherrschen mussten. Die Erstellung und Aktualisierung von Inhalten der Websites war zeitaufwändig und erforderte tiefgreifende technische Kenntnisse.

Durch das Aufkommen von Webpublishing-Tools, weiter in den frühen 90er Jahren, hat man verschiedene Webpublishing-Tools entwickelt, die die Erstellung von Webinhalten vereinfachen sollten. Diese Tools hat man damals auch über den Begriff WYSIWYG (What you see is what you get = Was du siehst, ist das, was du bekommst) kommuniziert. Beispiele hierfür sind Microsoft FrontPage und Adobe Dreamweaver. Diese Tools ermöglichten es Benutzern, Websites visuell zu erstellen, ohne direkt HTML-Code schreiben zu müssen. Allerdings hatten diese Werkzeuge ihre Einschränkungen. Insbesondere bei der Zusammenarbeit und der Verwaltung größerer Websites stieß man oftmals an die Grenzen dieser Tools. Auch musste man immer noch in den Code eingreifen, um individuelle Anpassungen vorzunehmen.

Die ersten Content Management Systeme

In den späten 90er Jahren entstanden die ersten Content-Management-Systeme, um die wachsenden Anforderungen an die Verwaltung von Webinhalten besser zu erfüllen. Diese frühen CMS ermöglichten es mehreren Benutzern, Inhalte gemeinsam zu erstellen und zu aktualisieren und boten eine bessere Struktur sowie Organisation für Websites.

Zu den ersten CMS gehörten Vignette StoryServer, Allaire Spectra und OpenMarket Content Server.

Mit dem Aufkommen von Open-Source-CMS und der Demokratisierung des Webpublishings in den frühen 2000er Jahren, kamen Lösungen wie WordPress, Joomla und Drupal zum Vorschein. Das Erstellen und Verwalten von Websites war nunmehr für eine breitere Masse zugänglich. Diese Systeme boten einfache Benutzeroberflächen, eine Vielzahl von Plugins und Erweiterungen und eine große Community-Unterstützung.

Ab 2010 ging dann die Anpassung an mobile Geräte und die zunehmende Bedeutung von Responsive Design los. Mit der Verbreitung von Smartphones und Tablets, war Responsive Design zu einer Notwendigkeit für moderne Websites geworden. CMS mussten sich anpassen, um die einfache Erstellung von Websites zu ermöglichen, die auf verschiedenen Geräten und Bildschirmgrößen funktionierten.

Heutzutage sind Content-Management-Systeme ein unverzichtbares Werkzeug für die Erstellung und Verwaltung von Websites und gehören zum Alltag. Sie haben sich ständig weiterentwickelt, um den wachsenden Anforderungen der Webentwicklung gerecht zu sein.

Heutzutage ist es für Benutzer weitestgehend möglich, ohne technischen Hintergrund ansprechende und funktionelle Websites zu erstellen.

Funktionen eines CMS

Ein CMS bietet eine Vielzahl von Funktionen, die die Erstellung und Verwaltung von Webinhalten erleichtern. Dazu gehören:

1.1. Benutzerfreundliche Oberfläche: Die meisten Content Management Systeme bieten eine intuitive, grafische Benutzeroberfläche, die es einfach macht, Inhalte zu erstellen, zu bearbeiten und zu organisieren.

1.2. Templates und Themes: Um ein einheitliches Erscheinungsbild der Website zu gewährleisten, nutzen CMS vorgefertigte Templates und Themes, die sich anpassen und individualisieren lassen.

1.3. Erweiterbarkeit: Content Management Systeme lassen sich häufig durch Plugins und Erweiterungen anpassen, um zusätzliche Funktionen hinzuzufügen.

1.4. Benutzerverwaltung und Zugriffskontrolle: Ein CMS ermöglicht die Verwaltung mehrerer Benutzer mit verschiedenen Rollen und Zugriffsebenen.

1.5. SEO-Optimierung: Content Management Systeme bieten oft integrierte Funktionen zur Optimierung der Website für Suchmaschinen.

Vorteile von CMS

2.1. Einfache Bedienung: Ein CMS erleichtert die Erstellung und Verwaltung von Webinhalten, auch für Benutzer ohne technischen Hintergrund.

2.2. Kosteneffizienz: Content Management Systeme sparen Kosten, da sie die Notwendigkeit reduzieren, professionelle Webentwickler für die Erstellung und Wartung einer Website einzustellen.

2.3. Skalierbarkeit: Ein Content Management System ermöglicht es, die Website problemlos zu erweitern und zu aktualisieren, um die wachsenden Anforderungen zu erfüllen.

2.4. Zusammenarbeit: Ein Content Management System erleichtert die Zusammenarbeit zwischen verschiedenen Teammitgliedern bei der Erstellung und Verwaltung von Inhalten.

2.5. Sicherheit: Viele CMS bieten Sicherheitsfunktionen wie regelmäßige Updates und Patches, um die Website vor potenziellen Bedrohungen zu schützen.

Beliebte CMS-Lösungen

3.1. WordPress: WordPress ist das weltweit bekannteste und am häufigsten eingesetzte CMS. Es ist bekannt für seine Benutzerfreundlichkeit, große Auswahl an Themes und Plugins sowie seine aktive Community. Den Beitrag dazu gibt es hier.

3.2. Joomla: Joomla ist ein leistungsfähiges und flexibles CMS, das sich besonders für komplexe Websites und Online-Anwendungen eignet. Es bietet erweiterte Funktionen und ist gut dokumentiert.

3.3. Drupal: Drupal ist ein leistungsstarkes und erweiterbares CMS, das sich ideal für große, komplexe Projekte eignet. Es ist bekannt für seine hohe Sicherheit und Skalierbarkeit.

3.4. Wix: Wix ist ein benutzerfreundliches CMS, das sich besonders für kleine Unternehmen und persönliche Websites eignet. Mit seiner Drag-and-Drop-Funktionalität können Benutzer ihre Websites einfach und schnell gestalten.

3.5. Squarespace: Squarespace ist ein weiteres benutzerfreundliches CMS, das sich durch seine stilvollen und modernen Vorlagen auszeichnet. Es ist besonders geeignet für kreative Berufe wie Fotografen, Designer und Künstler.

3.6. Shopify: Shopify ist ein spezialisiertes CMS für den E-Commerce-Bereich. Es bietet eine Vielzahl von Funktionen und Integrationen, die speziell auf den Online-Handel zugeschnitten sind.

3.7. TYPO3: TYPO3 ist ein leistungsstarkes, skalierbares und erweiterbares Open-Source-CMS, das sich besonders für große und komplexe Websites eignet. Es bietet eine Vielzahl von Funktionen und Erweiterungen und hat eine aktive Community.

Auswahl des richtigen CMS

Bei der Auswahl des richtigen Content Management Systems muss man verschiedene Faktoren berücksichtigen, wie:

4.1. Anforderungen: Die Anforderungen der Website bestimmen, welches CMS am besten geeignet ist. Man muss Überlegungen anstellen, welche Funktionen und Erweiterungen erforderlich sind, um die Ziele der Website zu erreichen.

4.2. Budget: Man sollte immer die Kosten für die Einrichtung und Wartung eines CMS berücksichtigen. Open-Source-Lösungen sind in der Regel kostengünstiger, während einige proprietäre Systeme höhere Gebühren erheben können.

4.3. Technische Kenntnisse: Einige Content Management Systeme erfordern mehr technische Kenntnisse als andere. Es ist wichtig, ein Content Management System zu wählen, das den Fähigkeiten des Individuums bzw. Teams entspricht.

4.4. Support und Community: Eine aktive Community und verfügbarer Support sind entscheidend für den Erfolg einer CMS-basierten Website. Man sollte immer prüfen, ob es ausreichend Ressourcen und Hilfestellungen gibt.

Fazit

Ein Content-Management-System ist ein wertvolles Tool für die Erstellung und Verwaltung von Webinhalten. Es gibt eine Vielzahl von CMS-Lösungen auf dem Markt, die sich in Funktionalität, Flexibilität und Benutzerfreundlichkeit unterscheiden. Bei der Auswahl eines CMS ist es wichtig, die spezifischen Anforderungen der Website, das Budget und die technischen Fähigkeiten des Individuums bzw. des Teams zu berücksichtigen. Mit dem richtigen CMS kann man die Online-Präsenz effektiv verwalten und optimieren, um die passende Zielgruppe zu erreichen.

Der Beitrag CMS – Inhalte mühelos verwalten erschien zuerst auf CEOsBay.

Der Zweck von REST liegt schwerpunktmäßig auf der Maschine-zu-Maschine-Kommunikation. REST stellt eine einfache Alternative zu ähnlichen Verfahren wie SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) und dem verwandten Verfahren RPC (Remote Procedure Call) dar. Anders als bei vielen verwandten Architekturen kodiert REST keine Methodeninformation in den URI (Uniform Resource Identifier), da der URI Ort und Namen der Ressource angibt, nicht aber die Funktionalität, die der Web-Dienst zu der Ressource anbietet. Der Vorteil von REST liegt darin, dass im WWW bereits ein Großteil der für REST nötigen Infrastruktur (z. B. Web- und Application-Server, https-fähige Clients, HTML- und XML-Parser, Sicherheitsmechanismen) vorhanden ist und viele Web-Dienste per se REST-konform sind. Eine Ressource kann dabei über verschiedene Medientypen dargestellt werden, auch Repräsentation der Ressource genannt.

So ist ein Online-Dienst, der lediglich unveränderte Seiteninhalte nach dem Internetstandard https anbietet, bereits REST-konform. Dynamisch erzeugte Seiten folgen diesem Paradigma jedoch meistens nicht. So bieten beispielsweise Nachrichtenseiten sich ständig ändernde Informationen mit sowohl unterschiedlichem Format als auch Inhalt an, die nur schwer automatisch verarbeitet werden können. Bliebe das Format unverändert, so wäre eine essenzielle REST-Eigenschaft erfüllt. So ist eine Webseite, auf der ständig die aktuelle Uhrzeit in immer demselben Format abrufbar ist, REST-konform.

Die Bezeichnung „Representational State Transfer“ soll den Übergang vom aktuellen Zustand zum nächsten Zustand (State) einer Applikation verbildlichen. Dieser Zustandsübergang erfolgt durch den Transfer der Daten, die den nächsten Zustand repräsentieren.

Kurze Zeitreise

Das REST-Paradigma entwickelte sich aus dem 1994 von Roy Fielding entworfenen https Object Model. Fielding entwickelte seine Idee von einem einheitlichen Konzept über die Jahre weiter, bis er 2000 den REST-Architekturstil im Rahmen seiner Dissertation (Hier der Link zu der Arbeit) veröffentlichte. Das Programmierparadigma der „RESTful Application“ wurde allerdings häufig falsch umgesetzt und findet erst seit 2014 Anklang in der Welt des WWW. In seiner Arbeit geht Fielding dabei auf die verschiedenen Anforderungen ein, die für die Webarchitektur wichtig sind.

Wie funktioniert REST?

Der Architektur-Stil verweist auf sechs Eigenschaften, die ein Dienst haben muss. Dabei ist nicht festgelegt, wie man diese Prinzipien implementieren muss. Fielding beschreibt für jedes Architekturprinzip dessen Vor- und Nachteile. Dabei handelt es sich um Client-Server, Zustandslosigkeit, Caching, Einheitliche Schnittstellen, Mehrschichtige Systeme und optional Code on Demand, auf die ich nachfolgend eingehen werde.

• Client-Server (Es gilt generell die Anforderung, dass alle Eigenschaften der Client-Server-Architektur gelten. Der Server stellt dabei einen Dienst bereit, der bei Bedarf vom Client abgefragt wird. Der Hauptvorteil dieser Anforderung ist die einfache Skalierbarkeit der Server, da diese unabhängig vom Client agieren. Dies ermöglicht des Weiteren eine unterschiedlich schnelle Entwicklung der beiden Komponenten.)
  
• Zustandslosigkeit (Jede REST-Nachricht enthält alle Informationen, die für den Server bzw. für den Client notwendig sind, um die Nachricht zu interpretieren. Weder der Server noch die Anwendung soll Zustandsinformationen zwischen zwei Nachrichten speichern. Man spricht daher von einem zustandslosen (englisch: stateless) Protokoll. Jede Anfrage eines Clients an den Server ist insofern in sich geschlossen, als dass sie sämtliche Informationen über den Anwendungszustand beinhaltet, die vom Server für die Verarbeitung der Anfrage benötigt. Zustandslosigkeit in der hier beschriebenen Form begünstigt die Skalierbarkeit eines Webservices. Beispielsweise können eingehende Anfragen im Zuge der Lastverteilung unkompliziert auf beliebige Maschinen verteilt werden, da jede Anfrage in sich geschlossen ist und Anwendungsinformationen somit ausschließlich auf der Seite des Clients vorgehalten werden. Aus diesem Grund ist auf der Seite des Servers keine Sitzungsverwaltung erforderlich. In der Praxis nutzen deswegen viele https-basierte Anwendungen Cookies und andere Techniken, um Zustandsinformationen auf der Client-Seite zu behalten. Weiterhin begünstigt wird die Ausfallsicherheit, weil die Zustandslosigkeit fordert, dass transaktionale Datenübertragung in einem einzigen Seitenaufruf erfolgt. Die Zustandslosigkeit bringt dabei aber den Nachteil mit, dass sich die Netzwerkperformance verschlechtert. Da bei jeder Abfrage alle Informationen zum Interpretieren mitgeschickt werden müssen, sind aufwendigere Abfragen nötig, als wenn sich der Server die Interaktionen merken würde.)
  
• Caching (https-Caching soll genutzt werden, wobei aber gilt: Eine Anfrage, die nicht gestellt werden muss, ist die schnellste Anfrage. Fielding führt dabei den Nachteil auf, dass der Client auf veraltete Cache-Daten zurückgreifen könnte, statt die neue Ressource abzufragen. Wir kennen dies beispielsweise, wenn wir an einer Website unsere Änderungen vorgenommen haben aber die aktualisierten Informationen nach der Synchronisierung mit dem Server nicht richtig angezeigt werden bzw. lediglich die alten Informationen)
  
• Einheitliche Schnittstelle (Dies ist das Hauptunterscheidungsmerkmal aller weiteren Architekturstile. Dabei besteht diese aus vier weiteren Eigenschaften.)

1. Die Adressierbarkeit von Ressourcen, bei der jede Information, die über einen URI kenntlich gemacht wird, als Ressource gekennzeichnet wird. Jeder REST-konforme Dienst eine eindeutige Adresse hat und dem Uniform Resource Locator (URL). Diese „Straße und Hausnummer im Netz“ standardisiert den Zugriffsweg zum Angebot eines Webservices für eine Vielzahl von Anwendungen (Clients). Eine konsistente Adressierbarkeit erleichtert es außerdem, einen Webservice als Teil eines Mashups weiterzuverwenden.
   
2. Repräsentationen zur Veränderung von Ressourcen, wodurch die unter einer Adresse zugänglichen Dienste unterschiedliche Darstellungsformen (Repräsentationen) haben können. Ein REST-konformer Server kann je nachdem, was die Anwendung anfordert, verschiedene Repräsentationen einer Ressource ausliefern, z. B. in verschiedenen Sprachen oder Formaten (HTML, JSON oder XML) oder auch die Beschreibung oder Dokumentation des Dienstes. Die Veränderung einer Ressource (also deren aktuellen Status) soll nur über eine Repräsentation erfolgen.
   
3. Selbstbeschreibende Nachrichten, REST-Nachrichten sollen selbstbeschreibend sein. Dazu zählt u. a. die Verwendung von Standardmethoden. Über diese Standardmethoden lassen sich Ressourcen manipulieren.
   
4. „Hypermedia as the Engine of Application State“ (HATEOAS) laut Fielding die wichtigste Eigenschaft

Ziel ist die Einheitlichkeit der Schnittstelle und somit ihre einfache Nutzung. 

• Mehrschichtige Systeme, bei dem die Systeme mehrschichtig aufgebaut sein sollen. Dadurch reicht es, dem Anwender lediglich eine Schnittstelle anzubieten. Dahinterliegende Ebenen können verborgen bleiben und somit die Architektur insgesamt vereinfachen. Vorteile dabei sind die bessere Skalierbarkeit der Server, sowie eine mögliche Abkapselung durch Firewalls. Durch Cache-Speicher an den Grenzen (z.B. vom Server zum Web) steigert man die Effizienz der Anfragen (Siehe Caching).
  
• Code on Demand, wobei diese Forderung von Fielding optional ist. Unter Code on Demand versteht man die Übertragung an den Client Code erst im Bedarfsfall. Folglich zur lokalen Ausführung. Ein Beispiel hierfür wäre die Übertragung von JavaScript-Code bei einer HTML-Repräsentation.

Folglich kommt für die Umsetzung des REST-Paradigmas ein zustandsloses Client-Server-Protokoll zum Einsatz. Als Anwendungsschicht-Protokolle werden hauptsächlich https und https eingesetzt. Dies liegt unter anderem daran, dass sich diese im WWW etabliert haben, über einen vergleichsweisen einfachen Aufbau verfügen und mit so gut wie jeder Firewall kompatibel sind. REST vereinheitlicht die Schnittstelle zwischen Systemen auf eine überschaubare und bezüglich des zu erwartenden Verhaltens standardisierte Menge von Aktionen. Welche Aktionen dies sind, ist in REST nicht festgelegt aber alle Aktionen sind allgemein definiert. In der Regel durch die verwendeten Protokolle der Anwendungsschicht.

Während REST als Abstraktion des WWW keine spezielle Implementierung und kein spezielles Protokoll fordert, ist doch zu beobachten, dass fast ausschließlich https zum Einsatz kommt. Dadurch werden auch die Menge der Aktionen festgelegt.

Wird über https zugegriffen, so gibt die verwendete https-Methode, darunter GET, POST, PUT und DELETE, an, welche Operation des Dienstes gewünscht ist. https schreibt vor, dass GET „safe“ (sicher) sein muss, was bedeutet, dass diese Methode nur Informationen beschafft und keine sonstigen Effekte verursacht. Die Methoden GET, HEAD, PUT und DELETE müssen laut https-Spezifikation idempotent (dasselbe) sein, was in diesem Zusammenhang bedeutet, dass das mehrfache Absenden der gleichen Anforderung sich nicht anders auswirkt als ein einzelner Aufruf. Abhängig von der Implementierung können noch weitere https-Befehle unterstützt werden. Dazu gehören COPY, MOVE, MKCOL, LOCK und UNLOCK des WebDAV-Protokolls, sowie LINK und UNLINK aus RFC 2068. Bei der Kommunikation über UDP kann zudem das CoAP aus RFC 7252 statt https eingesetzt werden, welches leicht abweichende Bedeutungen für GET, POST, PUT und DELETE besitzt.

Fazit

Die meisten Unternehmen verwenden den REST-Architekturstil für die Entwicklung / Implementierung von Webdiensten, da es sich um eine einfache und benutzerfreundliche Oberfläche handelt, die weniger Schulung für die vorhandenen / neuen Mitglieder des Projekts erfordert. Unternehmen erwägen REST zusammen mit ihren vorhandenen Webdiensten.

Der Beitrag REST – Schönheit der einfachen Architektur erschien zuerst auf CEOsBay.

Debian GNU/Linux basiert auf den grundlegenden Systemwerkzeugen des GNU-Projektes sowie dem Linux-Kernel.

Die aktuelle Version ist Debian 11 „Bullseye“ und als Vorabversion gibt es bereits Debian 12 „Bookworm“. Es bietet eine große Auswahl (Zurzeit ca. 60.000) an Anwendungsprogrammen und Werkzeugen. Auch wird Debian als Basis für viele andere Linux Distributionen genutzt. Eines der Bekannteren Ubuntu, welches eher nicht mehr zu meinen persönlichen Favoriten gehört.

So ging es los

Im August 1993 hat Ian Murdock mit der Arbeit an einem neuen Betriebssystem angefangen. Es sollte offen sein, ganz im Sinn von Linux und GNU. Er verschickte eine offene Einladung an andere Software-Entwickler und lud sie ein, bei einer Software-Distribution mitzumachen, die auf dem damals noch recht jungen Linux-Kernel basieren sollte. Debian sollte sorgfältig zusammengestellt und genauso gewissenhaft betreut und unterstützt werden. Dabei sollte es ein offenes Design aufweisen und Beiträge und Unterstützung aus der Freien-Software-Gemeinschaft einfließen lassen.

Alles begann mit einer kleinen, eingeschworenen Gruppe von Hackern von freier Software und wuchs zu einer relativ großen, gut organisierten Gruppe aus Entwicklern, Beitragenden und Anwendern heran. Mittlerweile fasst das Debian-Projekt mehr als eintausend aktive Entwickler und Unterstützer auf der ganzen Welt.

Die Satzung

Ein Projekt mit dieser Größe braucht eine gute Organisationsstruktur. Aus diesem Grund hat das Debian-Projekt klare Regeln und Richtlinien, die man hier unter der Satzung einsehen kann.

Debian – Das Wieso

Manche wundern sich, warum so viele Menschen dafür brennen, so viel Freizeit in das Programmieren, Verpacken und Betreuen von Software zu investieren und sie dann auch noch zu verschenken. Dafür gibt es eine ganze Reihe von Gründen.

Manche Leute sind von Natur aus einfach hilfsbereit und haben mit der Einbringung in ein freies Software-Projekt ihren Weg gefunden, diese Hilfsbereitschaft auszuleben.

Viele Entwickler schreiben Programme, um Computer sowie verschiedene Architekturen und Programmiersprachen besser zu verstehen.

Einige Unterstützer möchten sich für all die freie Software revanchieren, die sie benutzen dürfen und bringen sich deshalb ein. 

Dann gibt es noch viele AkademikerInnen, die an freier Software entwickeln, um ihre Kenntnisse zu erweitern und um die Ergebnisse ihrer Forschungen bekannt zu machen.

Und zu guter Letzt gibt es Unternehmen, die bei der Entwicklung und Betreuung von freier Software helfen, um Einfluss darauf zu nehmen, wie sich die Software weiterentwickelt. Besonders dann, wenn man neue Features schnell implementiert haben möchte.

Ich persönlich bin bei dem ein oder anderen Projekt dabei, weil mich die Technologie an sich interessiert und mir die Zusammenarbeit mit Menschen sehr viel Spaß macht. Und nachdem mir relativ schnell langweilig wird, benötige ich immer wieder neuen Input. Letzteres gilt natürlich für die Technologie und weniger für die Menschen. Im Grunde genommen, beteiligt man sich meistens an Open Source bzw. in diesem Kontext als Debian-Entwickler, für den Spaß und um gemeinsam etwas großartiges zu erschaffen.

Ideologie und unfreie Software

Die Debian Gemeinschaft glaubt an die freie Software. Dennoch ist es respektiert, dass Menschen manchmal unfreie Software auf ihren Computern installieren müssen. Aus diesem Grund gibt es den Beschluss seitens der Debian Entwickler, diese Menschen nach Möglichkeit zu unterstützen, daher gibt es eine immer größer werdende Anzahl von Paketen, die unfreie Software auf einem Debian-System nachinstallieren lässt.

Diese Tatsache kann besonders zu Beginn relativ herausfordernd sein, da man bereits zur Installation von Debian nicht freie Treiber Pakete für diverse Hardware installieren muss, die nicht standardmäßig auf den Installationsmedien mitgeliefert werden. Besonders betroffen hierbei, sind in der Regel die Treiber für die Netzwerkkarte, da man diese bereits bei der Installation benötigt, um aktualisierte Pakete bereits bei der initialen Installation mitzuinstallieren. Doch dies werde ich, mit einer hohen Wahrscheinlichkeit, bei einem späteren Beitrag nochmals ausführlich thematisieren.

Das Projekt

So gesehen, kann sich jeder als Debian Entwickler registrieren, der den sogenannten New-Member-Prozess erfolgreich durchläuft. Die Bewerber kommen hinsichtlich ihrer Kenntnisse und Fähigkeiten auf den Prüfstand. Außerdem wird sichergestellt, dass sie mit der Philosophie des Projektes vertraut sind.

Der Name des Betriebssystems leitet sich von den Vornamen des Debian-Gründers Ian Murdock und seiner damaligen Freundin und späteren Ehefrau Debra Lynn ab. Bereits wenige Monate nach der Gründung, im Mai 1994, entschied sich das Projekt zu einer Änderung des offiziellen Namens von Debian zu Debian GNU/Linux.

Letzteres ging mit der Auffassung der Free Software Foundation einher, dass das häufig als Linux bezeichnete Betriebssystem eine Variante des GNU-Systems sei. Dahingehend gab es einen relativ bekannten Namensstreit, den ich hier nicht wirklich thematisieren werde. Wen es aber interessiert, kann gerne hier vorbeischauen.

Allgemein spricht man nur noch von Debian, wenn man von Debian spricht 😀

Das System ist bekannt für seine Paketverwaltung dpkg und deren Frontend APT. Mit diesen ist es möglich, alte Versionen von Debian GNU/Linux durch aktuelle zu ersetzen oder neue Softwarepakete zu installieren. Sie sind ebenfalls dafür zuständig, alle von einem Programm benötigten Abhängigkeiten aufzulösen, also alle Programmpakete zu laden und zu installieren, welche die gewünschte Software benötigt.

Sicherheit

Alle Probleme mit der Software sind öffentlich behandelt, so auch sämtliche Sicherheitsprobleme. Aspekte der Sicherheit sind öffentlich auf der debian-security-announce-Mailingliste zur Diskussion freigegeben. Debian‘s Sicherheitsgutachten (Audits) werden über eine öffentliche Mailingliste versendet (Sowohl unter den Entwicklern als auch mit den externen Mailinglisten) gleichzeitig auf einem öffentlichen Server bekanntgegeben.

Durch diese Handhabung verspricht man sich ein schnelleres Auffinden von Sicherheitslücken und damit die Möglichkeit, diese auch eher beheben zu können. Die entgegengesetzte Herangehensweise des Security Through Obscurity (Sicherheit durch Unklarheit bedeutet, dass man sich in der Sicherheitstechnik auf die Geheimhaltung des Entwurfs oder der Implementierung als Hauptmethode zur Gewährleistung der Sicherheit eines Systems oder einer Komponente verlässt) ist dagegen als unpraktikabel angesehen. 

Die Tatsache, dass die Entwicklung der Distribution öffentlich sichtbar unter Beteiligung einer Vielzahl von Personen geschieht, erfordert besondere Sicherheitsmaßnahmen. Änderungen an Paketen sind grundsätzlich mit einem verifizierbaren Schlüssel digital signiert. Die Überprüfung der Gültigkeit der Signatur erfolgt beim Anwender vor der Installation. Diese Maßnahme soll es Dritten erschweren, schädliche Software in Debian-Pakete einzuschleusen.

Die Paketbetreuer passen die Sicherheitsaspekte ihrer jeweiligen Software an die allgemeinen Grundsätze von Debian an. Daher sind Dienste nach der Installation oft als „sicher“ voreingestellt, was von einem Benutzer als „Einschränkung“ empfunden werden kann. Dennoch versucht Debian, Sicherheitsaspekte und einfache Administration abzuwägen. Zum Beispiel werden Dienste wie ssh und ntp nicht inaktiv installiert, wie es bei den Distributionen der BSD-Familie üblich ist. Auf BSD werde ich in einem zukünftigen Beitrag eingehen.

Wenn ein Sicherheitsproblem in einem Debian-Paket entdeckt wird, kommt es zusammen mit einer Einschätzung der dadurch entstehenden Gefahr in die Öffentlichkeit bzw. wird auf den vorher erwähnten Wegen publiziert. Parallel wird so schnell wie möglich ein Sicherheitsupdate dieses Pakets vorbereitet und auf speziellen Servern veröffentlicht. Kritische Sicherheitslücken werden auf diese Weise häufig innerhalb von Stunden geschlossen.

An dieser Stelle ist es vielleicht sinnvoll zu erwähnen, dass die von Debian angepasste Implementierung des für die Schlüsselerstellung zuständigen Zufallsgenerators der OpenSSL-Bibliothek zwischen September 2006 und Mai 2008 mit einer erheblichen Sicherheitslücke lief. Die generierten geheimen Schlüssel konnten abgeschätzt und damit in kurzer Zeit (vor-)berechnet werden (1024- und 2048-Bit-Schlüssel in ungefähr zwei Stunden). Insbesondere OpenSSH und die sichere Kommunikation in Webbrowsern waren davon betroffen.

Das Sicherheitsrisiko besteht weiterhin für alle RSA-Schlüssel, die in diesem Zeitraum auf betroffenen Systemen erstellt wurden und seit der Aktualisierung der Bibliothek nicht neu erstellt wurden. Auch alle DSA-Schlüssel, die jemals von einem Rechner mit fehlerhaftem Zufallszahlengenerator verwendet wurden, sind seitdem unsicher. Selbst wenn diese ursprünglich auf einem Rechner mit korrekt arbeitendem Zufallszahlengenerator erstellt wurden. Zu einem der größeren Sicherheitslücken kam es auch im Jahr 2019. Denn da wurde in dem Paketmanagertool von Debian („apt“ bzw. „apt-get“) eine Sicherheitslücke entdeckt, die es einem Man-in-the-Middle-Angreifer ermöglichte Code bei einem Update auszuführen.

Fun Facts

Die Stadt München war zwischen 2006 und 2013 mit Debian-basierten Betriebssystemen LiMux auf freier Software unterwegs. Spekulationen zufolge switchten sie durch Einfluss von Microsoft, da sie mit einer Deutschland-Zentrale von Unterschleißheim nach München-Schwabing umzogen, zu Microsoft. Dies könnte mit der Gewerbesteuer an die Stadt München zusammenhängen, meinte der ein oder andere Autor im Manager-Magazin.

Fazit

Wie bereits erwähnt, empfinde ich Debian als äußerst sympathisches Projekt bzw. Distribution. Nichtsdestotrotz ist es, meiner Meinung nach, noch kein einsteigerfreundliches Betriebssystem. Zum einen, wegen der unfreien Treiber, die gegebenenfalls vor- oder nachinstalliert werden müssen und zum anderen, weil grundsätzlich jedes System nach der Neuinstallation Sicherheitslücken enthält, die von fähigen Personen geschlossen werden müssen. Debian GNU/Linux bietet umfangreiche Möglichkeiten, das System vor unbefugten Zugriffen abzuschotten. Allerdings reicht es nicht aus nur Sicherheits-Updates aufzuspielen. Der Anwender selbst kann und muss aktiv sein System „härten“. Und dafür muss man schon einiges an Fachwissen mitbringen.

Sicherlich kann sich der Nutzer über Sicherheitsrisiken unter den genannten Quellen bereits im Vorfeld informieren. Doch auch während und nach der Installation des Debian-Betriebssystems muss der Nutzer auf einige grundlegende Dinge achten. Dies beginnt bei den BIOS-Einstellungen, geht über die Absicherung des Bootloaders und schlussendlich bei der Installation von Sicherheits-Patches bzw. zur Anpassung von Diensten und sicherheitsrelevanten Dateien.

Daher ist es vielleicht sinnvoll, mit einem „einfacheren“ System wie Ubuntu zu beginnen und sich so langsam in die Materie einzuarbeiten, wenn man in der Zukunft etwas unabhängiger und konsequenter unterwegs sein will.

Der Beitrag Debian – Für Stabilität und Freiheit erschien zuerst auf CEOsBay.