Geschichte der URL

Die Geschichte ist untrennbar mit der des Internets verbunden. Tim Berners-Lee, ein britischer Informatiker, entwickelte Ende der 1980er Jahre das World Wide Web. Dabei wurde die Notwendigkeit einer standardisierten Methode erkannt, um Ressourcen im Netz eindeutig zu identifizieren und darauf zuzugreifen. Aus diesem Bedarf heraus entstand 1991 die URL.

Aufbau einer URL

Typischerweise besteht sie aus mehreren Teilen:

1. Protokoll: Definiert, welches Übertragungsprotokoll man verwendet (z.B. HTTP, HTTPS, FTP).
2. Domainname: Gibt die Webseite oder den Server an, auf den zugegriffen wird.
3. Pfad: Spezifiziert den genauen Ort der Ressource auf dem Server.
4. Parameter: Optionale Informationen, die man an den Server sendet.

Beispiel: https://www.beispiel.de/pfad/unterpfad?parameter=wert

Beste Praktiken bei der Umsetzung von URLs

Die Erstellung einer klaren, konsistenten und benutzerfreundlichen URL-Struktur bietet zahlreiche Vorteile:

• Benutzerfreundlichkeit: Kurze, beschreibende URLs helfen dabei, den Inhalt der Seite vor dem Klick zu erahnen.
• Suchmaschinenoptimierung (SEO): Klare und relevante URLs bewerten Suchmaschinen positiv. Dies erleichtert die Indexierung und das Ranking der Seite. Siehe auch den Beitrag über SEO.
• Sharing: Gut strukturiert lässt es sich einfacher teilen und merken.

Tipps für optimierte URLs:

• Klarheit: Klare und verständliche Wörter verwenden.
• Kürze: Unnötige Wörter und Pfade vermeiden.
• Struktur: Bindestriche anstelle von Unterstrichen verwenden, um Wörter zu trennen.
• Dynamische Parameter vermeiden: Wo möglich, statische, beschreibende URLs verwenden.

Worauf zu achten ist

• Sicherheit: HTTPS verwenden, um den Datenverkehr zu verschlüsseln.
• Duplizierte Inhalte: Sicherstellen, dass jede Seite eine eindeutige URL besitzt.
• Weiterleitungen: Bei geänderten URLs 301-Weiterleitungen nutzen.

Fazit

Die URL ist ein zentrales Element des Webs und fungiert nicht nur als digitale Adresse, sondern auch als Instrument für Markenpräsenz und Benutzererfahrung. Durch Verständnis ihrer Geschichte und Beachtung der besten Praktiken lässt sich die Effektivität und Reichweite einer Webseite steigern.

Der Beitrag URL – Von ihrer Entstehung bis zur modernen Optimierung erschien zuerst auf CEOsBay.

Grundlagen von JSON Web Tokens

JWTs sind als offener Standard definiert (RFC 7519) (Siehe Beitrag über RFC und HAL) und sind in vielen Programmiersprachen und Plattformen implementiert. Ein JWT besteht aus drei Teilen: Header, Nutzlast (Payload) und Signatur. Diese Teile sind durch Punkte getrennt und bilden einen kompakten Token, die man beispielsweise in einem https-Header oder einer URL übertragen kann.

Struktur von JWT

Header

Der Header enthält Informationen über den verwendeten Algorithmus zur Signatur des Tokens und den Token-Typ. Typischerweise sieht ein Header folgendermaßen aus:

{
"alg": "HS256",
"typ": "JWT"
}

Nutzlast (Payload)

Die Nutzlast enthält die eigentlichen Informationen, die man zwischen den Parteien austauscht. Diese Informationen bezeichnet man auch als Claims. Der Payload kann sowohl vordefinierte als auch benutzerdefinierte Claims enthalten.

Siehe nachfolgendes Beispiel:

{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}

oder

{
  "user_id": "42"
}

Im zweiten Beispiel ist user_id der Claim-Schlüssel und 42 der zugehörige Wert. Diesen Claim kann man beispielsweise in einem JWT verwenden, um den authentifizierten Benutzer zu identifizieren.

Signatur

Die Signatur dient dazu, die Integrität des Tokens sicherzustellen und zu verhindern, dass man dessen Inhalt manipulieren kann. Dier Erstellung erfolgt durch die Verwendung eines geheimen Schlüssels und des im Header angegebenen Algorithmus (z. B. HMAC-SHA256).

Vorteile von JWT

Stateless und skalierbar

JWTs ermöglichen eine stateless Authentifizierung, da die Nutzlast alle erforderlichen Informationen enthält. Dies bedeutet, dass man keine Sitzungsdaten auf der Serverseite speichern muss. Dadurch sind und bleiben Anwendungen leichter skalierbar.

Einfache Implementierung

Da JWTs auf dem weit verbreiteten JSON-Format basieren, ist ihre Implementierung einfach und sie unterstützt eine Vielzahl von Bibliotheken und Frameworks.

Selbstenthaltend

JWTs enthalten alle erforderlichen Informationen in sich selbst. Dadurch sind keine zusätzlichen Datenbankabfragen zur Verifizierung des Benutzers erforderlich.

Nutzungsszenarien von JWT

Authentifizierung

Man nutzt JWTs häufig zur Authentifizierung von Benutzern in Single-Page-Anwendungen (SPAs) Single Page Applications und APIs.

Autorisierung

Man kann ein JWT auch zur Autorisierung verwenden. Dies lässt sich bewerkstelligen, sofern Informationen über die Rollen und Berechtigungen des Benutzers in den Claims des Tokens enthalten sind.

Informationen teilen

Da JWTs einfach zu erstellen und zu verifizieren sind, kann man sie verwenden, um Informationen zwischen verschiedenen Diensten oder Parteien sicher auszutauschen.

Sicherheitsbedenken und Best Practices

Sichere Übertragung

Man sollte JWTs immer über sichere Kommunikationskanäle wie https übertragen, um Man-in-the-Middle-Angriffe zu verhindern.

Gültigkeit bzw. Ablaufzeit

Tokens sollten eine Gültigkeit bzw. Ablaufzeit (Expiration Time) enthalten, um das Risiko einer Kompromittierung zu minimieren. Sobald ein Token abgelaufen ist, kann man nicht mehr auf die Ressource zugreifen. Dies schafft eine weitere Sicherheitsinstanz, da der Angreifer, selbst wenn er den Zugang gehacked hat, im Besitz des immer wieder neu generierten Tokens sein muss.

Aufbewahrung von geheimen Zugangsdaten

Man sollte den geheimen Schlüssel, den man zur Signatur von JWTs verwendet, sicher aufbewahren und vor unbefugtem Zugriff schützen.

Die Wahl des richtigen Algorithmus

Man sollte einen sicheren Algorithmus für die Signatur von Tokens verwenden. Beispielsweise HMAC-SHA256 oder RSA. Dies, davon ist auszugehen, kann sich mit der fortschreitenden Entwicklung der Quantencomputertechnologie ändern. Folglich ist es immer von enormer Wichtigkeit, die Entwicklungen dahingehend zu beobachten.

Token – Hijacking)

Man sollte darauf achten, dass JWTs nicht im Local Storage oder Session Storage des Browsers gespeichert sind. Dies kann die Seite bzw. Anwendung anfällig für Cross-Site-Scripting-Angriffe (XSS) machen. Daher kann es Sinn machen, https-Only-Cookies zu verwenden.

Fazit

JSON Web Tokens bieten eine moderne, flexible und sichere Methode zur Authentifizierung und Autorisierung von Benutzern in Webanwendungen und APIs. Durch die Stateless-Natur, einfache Implementierung und Selbstenthaltung von JWTs lassen sich skalierbare Lösungen für die Identitätsverwaltung erstellen. Dennoch sollte man sich der Sicherheitsrisiken bewusst sein und Best Practices befolgen, um die Integrität und Sicherheit der Anwendung zu gewährleisten.

Der Beitrag JWT – JSON Web Tokens – Die moderne Authentifizierungsmethode erschien zuerst auf CEOsBay.

Es stützt sich auf XML zur Repräsentation der Daten und auf Internet-Protokolle der Transport- und Anwendungsschicht zur Übertragung der Nachrichten. Die gängigste Kombination ist SOAP über https (Hypertext Transfer Protocol) und TCP (Transmission Control Protocol). Man kann SOAP auch über das SMTP (Simple Mail Transfer Protocol) oder JMS (Jakarta Messaging) verwenden.

Die mit der Nachricht übermittelten Nutzdaten man nicht zwingend in XML senden. Andere Formate wie Base64 oder CSV sind ebenfalls möglich. Seit Version 1.2. nutzt man die Abkürzung SOAP offiziell nicht mehr als Akronym, da es erstens (subjektiv) keineswegs einfach (Simple) ist und zweitens nicht nur dem Zugriff auf Objekte (Object Access) dient.

Kurze Zeitreise

SOAP entstand aus der Weiterentwicklung der Spezifikation für XML-RPC im Jahr 1998. Hauptverantwortlicher Software-Entwickler damals Dave Winer und seine Firma UserLand Software in engem Austausch mit Microsoft. Dave Winter ist übrigens auch für RSS 2.0 verantwortlich. Einen Beitrag über RSS findet man hier.

Im Jahr 1999 fand die Veröffentlichung der Version 1.0 von SOAP statt. Dies stellt unter Anderem den Zeitpunkt dar, an dem die Entwicklung mehr Unterstützung fand. Vor allem hat sich IBM im Jahr 2000 der Entwicklung angeschlossen, was dazu führte, dass IBM, Microsoft, DevelopMentor (Don Box) und UserLand Software (Dave Winer) die Spezifikation von SOAP 1.1 beim World Wide Web Consortium (W3C) einreichten. Dabei hat man das Ziel verfolgt, eine Arbeitsgruppe zu gründen, die SOAP weiterentwickeln sollte. Das Ergebnis dieser Arbeitsgruppe ist SOAP Version 1.2, empfing im Juni 2003 die Anerkennung als recommendation (Empfehlung).

Wie zu Beginn des Beitrags erwähnt, hat man SOAP nicht mehr als gebräuchliche(s) Akronym bzw. Abkürzung verstanden. Der Hauptgrund dafür ist die Tatsache, dass sämtliche Deutungen für SOAP, wie Simple Object Access Protocol oder Service Oriented Architecture Protocol, nicht mehr den vollständigen Sinn von SOAP trafen. Dies ermöglichte die Anmeldung von SOAP als Markennamen in den USA.

Wie funktioniert SOAP?

SOAP ist wie zuvor beschrieben, ein Protokoll zum Austausch XML-Information-Set-basierter Nachrichten über ein Rechnernetz und hat den Status einer W3C-Empfehlung. Es stellt Regeln für das Nachrichtendesign auf. Regelt, wie Daten in der Nachricht abzubilden und zu interpretieren sind. Es gibt eine Konvention für entfernte Prozeduraufrufe mittels SOAP-Nachrichten vor. SOAP macht keine Vorschriften zur Semantik applikationsspezifischer Daten, die man gegebenenfalls versendet möchte, sondern stellt ein Framework (Siehe meinen Beitrag) zur Verfügung, welches erlaubt, dass man beliebige applikationsspezifische Informationen übertragen kann.

Man kann SOAP für entfernte Prozeduraufrufe ebenso nutzen wie für einfache Nachrichtensysteme. Zum Senden von Nachrichten kann man beliebige Transportprotokolle verwendet. Dazu gehören beispielsweise FTP, SMTP, https oder auch JMS. Aus Gründen der Kompatibilität nutzt man in der Praxis hierzu gängige Netzwerk-Architekturen. Auch ist mittels https die verschlüsselte Übertragung von SOAP-Nachrichten möglich. Das ermöglicht jedoch keine End-to-End-Verschlüsselung. Dies kann man durch WS-Security erreichen. Die Einbindung erfolgt lediglich auf der Ebene der Nachrichten und nicht auf der des unterliegenden Transportprotokolls. Folglich ist es so, dass man das XML Information Set der SOAP-Anfrage bei Nutzung von https(S) im Body eines https POST Requests als XML an eine gegebene URL schickt.

In der Regel setzt man SOAP da ein, wo der direkte Zugang fremder Systeme zu einer Informationsquelle nicht sinnvoll erscheint. Dies kann sowohl an Kompatibilitätsproblemen zwischen verschiedenen Anwendungsarchitekturen liegen aber auch an diversen Sicherheitsaspekten. So kann man einen (partiellen) Zugriff auf eine Datenbank ermöglichen, ohne dem Anwenderprogramm den direkten Zugang zu ermöglichen. Die Menge der ausführbaren Methoden reglementiert und definiert man über die SOAP-Schnittstelle.

Die Kommunikation mit SOAP ermöglicht die Kopplung von Systemen. Der offene Entwurf ermöglicht jedoch lediglich den Aufbau schwach gekoppelter Systeme. Die Flexibilität des Konzeptes erkauft man sich durch die Nachteile beim Übertragungsvolumen und Rechenaufwand. Dies kann teuer werden, da man das XML-Dokument beim Sender zunächst aufbaut und anschließend validiert. Das Konzept verfolgt eigentlich das Ziel eines leichtgewichtigen Protokolls.

Doch durch den flexiblen Einsatzbereich führt die zu übertragende Datei eine Reihe von Metadaten mit sich, die bei der Konstruktion des XML-Dokuments weiter anwächst. So führt beispielsweise das einfache Versenden von „Wahr“ oder „Falsch“ zu einem Datenvolumen von mehreren hundert Bytes. In einem stark gekoppelten System sollte dafür theoretisch ein Bit reichen.

Durch die Möglichkeit des flexiblen Aufbaus des Dokuments kann man jedoch auch komplexe Transaktionen in einer Anfrage atomar zusammenfassen, während man in stark gekoppelten Systemen hierzu oftmals mehrere Anfragen erstellen muss. Dies verbessert das Nutzlastverhältnis (Nutzdaten zu Meta-Daten) und den Kommunikationsaufwand (für den Aufbau einer Verbindung, nur ein Senden/Empfangen).

SOAP unterscheidet zwischen dem endgültigen Empfänger und den Zwischenempfängern. Dies ermöglicht es, eine Nachricht über verschiedene „Hops“ zu schicken, bei denen man sogar verschiedene Transportprotokolle verwendet. Beispielsweise kann man zum ersten Hop die Nachricht mittels Java Message Service schicken, im Anschluss über E-Mail und schließlich dem Empfänger mittels https weitergeben. Der Absender muss über die Zwischenhops keine Information haben, die Middleware jedoch schon.

Wie ist eine SOAP-Nachricht aufgebaut?

Eine minimale SOAP-Nachricht besteht aus einem Envelope genannten Element, dem man einen lokalen Namen zuweisen muss. Dieses Element referenziert mittels eines Namensraum-Attributes auf https://www.w3.org/2003/05/soap-envelope. Child dieses Elements muss ein Body-Element sein. Optional kann zuvor ein Header-Element stehen. In diesem kann man Meta-Informationen, beispielsweise zum Routing, zur Verschlüsselung oder zu Transaktionsidentifizierung, unterbringen. Im Body-Element sind die eigentlichen Nutzdaten untergebracht. Dies sieht dann folgendermaßen aus:

<?xml version="1.0"?>
<s:Envelope xmlns:s="https://www.w3.org/2003/05/soap-envelope">
    <s:Header>
    </s:Header>
    <s:Body>
    </s:Body>
</s:Envelope>

Innerhalb des Body-Elements können sowohl Informationen zum Datenaustausch als auch Anweisungen für einen entfernten Prozeduraufruf stehen. Dies ist vom Empfänger entsprechend zu interpretieren.

Im Header gibt man den nächsten Hop (intermediary) und den endgültigen Empfänger (ultimate recipient) an. Ein intermediary kann beispielsweise die Nachricht verschlüsseln, sie loggen oder die Nachricht aufteilen. Ersteres erlaubt es, dass die Anwendungslogik sich nicht um die Sicherheit der Nachricht kümmern muss. Darum kümmert sich die Middleware. Was eine Middleware ist, erkläre ich in einem anderen Beitrag. Die Möglichkeit, dass Intermediaries beliebige Dinge tun können, ermöglicht EAI (Enterprise Application Integration).

Fazit

Viele Altsysteme verwenden möglicherweise noch SOAP. In der Vergangenheit war es auch die Lösung schlechthin. Heute ist es eher REST, welches zum Einsatz kommt und in webbasierten Szenarien häufig als die schnellere Alternative gilt.

Zusammengefasst kann man sagen, dass REST aus einer Reihe von Richtlinien für eine flexible Implementierung besteht und SOAP ein Protokoll mit spezifischen Anforderungen wie XML-Messaging ist.

REST-APIs sind schlank und daher ideal für moderne Anwendungen geeignet, wie das Internet of Things (IoT), mobile Anwendungen und Serverless Computing. SOAP-Webservices bieten zwar integrierte Sicherheit und Transaktions-Compliance, die vielen Unternehmensanforderungen entspricht, doch die Erstellung und Wartung ist wesentlich aufwändiger. Darüber hinaus folgen auch viele öffentlich zugängliche APIsheutzutage, den REST-Richtlinien.

Der Beitrag SOAP – Effiziente Möglichkeit, um Daten zwischen Systemen zu übertragen 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.