Was genau ist RESTful-Programmierung?
Antworten
Zu viele Anzeigen?Was ist REST?
REST ist ein architektonischer Stil, der auf bestimmten Prinzipien aufbaut und die aktuellen "Web"-Grundlagen nutzt. Es gibt 5 Grundprinzipien des Webs, die zur Erstellung von REST-Diensten genutzt werden.
- Grundsatz 1: Alles ist eine Ressource In der REST-Architektur werden Daten und Funktionen als Ressourcen betrachtet, auf die über Uniform Resource Identifiers (URIs), in der Regel Links im Web, zugegriffen wird.
- Grundsatz 2: Jede Ressource wird durch einen eindeutigen Bezeichner (URI) identifiziert
- Grundsatz 3: Einfache und einheitliche Schnittstellen verwenden
- Grundsatz 4: Die Kommunikation erfolgt durch Repräsentation
- Grundsatz 5: Staatenlos sein
Ich sehe eine Reihe von Antworten, die sagen, dass alles über den Benutzer 123 in der Ressource "/user/123" RESTful ist.
Roy Fielding, der den Begriff geprägt hat, sagt REST-APIs müssen hypertextgesteuert sein . Insbesondere "darf eine REST-API keine festen Ressourcennamen oder -hierarchien definieren".
Wenn also der Pfad "/user/123" auf dem Client hart kodiert ist, handelt es sich nicht wirklich um RESTful. Eine gute Nutzung von HTTP, vielleicht, vielleicht auch nicht. Aber nicht RESTful. Es muss aus dem Hypertext kommen.
Die Antwort ist ganz einfach: Es gibt eine Dissertation geschrieben von Roy Fielding]. 1 In dieser Dissertation definiert er die REST-Prinzipien. Wenn eine Anwendung alle diese Prinzipien erfüllt, dann ist sie eine REST-Anwendung.
Der Begriff "RESTful" wurde geschaffen, weil das Wort "REST" ausgenutzt wurde, indem man seine Nicht-REST-Anwendung als "REST" bezeichnete. Danach war auch der Begriff RESTful erschöpft. Heutzutage sprechen wir über Web APIs und Hypermedia APIs da die meisten der so genannten REST-Anwendungen den HATEOAS-Teil der einheitlichen Schnittstellenbedingung nicht erfüllen.
Die REST-Beschränkungen sind die folgenden:
-
Client-Server-Architektur
Es funktioniert also nicht mit z.B. PUB/SUB-Sockets, sondern basiert auf REQ/REP.
-
zustandslose Kommunikation
Der Server verwaltet also nicht die Zustände der Clients. Dies bedeutet, dass Sie keine serverseitige Sitzungsspeicherung verwenden können und jede Anfrage authentifizieren müssen. Ihre Clients senden möglicherweise grundlegende Authentifizierungs-Header über eine verschlüsselte Verbindung. (Bei großen Anwendungen ist es schwierig, viele Sitzungen zu verwalten).
-
Nutzung des Cache, wenn Sie können
So müssen Sie nicht immer wieder die gleichen Anfragen stellen.
-
einheitliche Schnittstelle als gemeinsamer Vertrag zwischen Client und Server
Der Vertrag zwischen dem Client und dem Server wird nicht vom Server aufrechterhalten. Mit anderen Worten: Der Client muss von der Implementierung des Dienstes entkoppelt sein. Dieser Zustand kann durch die Verwendung von Standardlösungen erreicht werden, z. B. dem IRI-Standard (URI) zur Identifizierung von Ressourcen, dem HTTP-Standard zum Austausch von Nachrichten, Standard-MIME-Typen zur Beschreibung des Serialisierungsformats des Nachrichtenkörpers, Metadaten (möglicherweise RDF-Vokabeln, Mikroformate usw.) zur Beschreibung der Semantik verschiedener Teile des Nachrichtenkörpers. Um die IRI-Struktur vom Client zu entkoppeln, müssen Hyperlinks in Hypermedia-Formaten (HTML, JSON-LD, HAL usw.) an die Clients gesendet werden. So kann ein Client die Metadaten (möglicherweise Link-Relationen, RDF-Vokabeln), die den Hyperlinks zugeordnet sind, nutzen, um den Zustandsautomaten der Anwendung durch die richtigen Zustandsübergänge zu navigieren, um sein aktuelles Ziel zu erreichen.
Wenn zum Beispiel ein Kunde eine Bestellung an einen Webshop senden möchte, muss er die Hyperlinks in den Antworten des Webshops überprüfen. Bei der Überprüfung der Links findet er einen, der mit dem http://schema.org/OrderAction . Der Client kennt das schema.org-Vokabular und versteht daher, dass durch die Aktivierung dieses Hyperlinks die Bestellung gesendet wird. Er aktiviert also den Hyperlink und sendet eine
POST https://example.com/api/v1/order
Nachricht mit dem richtigen Text. Danach verarbeitet der Dienst die Nachricht und antwortet mit dem Ergebnis, das den richtigen HTTP-Status-Header hat, zum Beispiel201 - created
durch Erfolg. Um Nachrichten mit detaillierten Metadaten zu versehen, ist die Standardlösung die Verwendung eines RDF-Formats, zum Beispiel JSON-LD mit einem REST-Vokabular, zum Beispiel Hydra und bereichsspezifische Vokabeln wie schema.org oder jede andere Linked-Data-Vokabular und eventuell ein anwendungsspezifisches Vokabular, falls erforderlich. Dies ist nicht einfach. Deshalb verwenden die meisten Anwender HAL und andere einfache Formate, die in der Regel nur ein REST-Vokabular, aber keine Unterstützung für verknüpfte Daten bieten. -
Aufbau eines mehrschichtigen Systems zur Verbesserung der Skalierbarkeit
Das REST-System ist aus hierarchischen Schichten aufgebaut. Jede Schicht enthält Komponenten, die die Dienste der Komponenten der nächsttieferen Schicht nutzen. Sie können also mühelos neue Schichten und Komponenten hinzufügen.
So gibt es beispielsweise eine Client-Schicht, die die Clients enthält, und darunter eine Service-Schicht, die einen einzelnen Dienst enthält. Nun können Sie einen clientseitigen Cache zwischen den beiden Schichten einfügen. Danach kann man eine weitere Dienstinstanz und einen Load Balancer hinzufügen, und so weiter... Der Client-Code und der Service-Code werden sich nicht ändern.
-
Code nach Bedarf zur Erweiterung der Client-Funktionalität
Diese Einschränkung ist fakultativ. Sie können zum Beispiel einen Parser für einen bestimmten Medientyp an den Client senden, und so weiter... Um dies zu tun, benötigen Sie möglicherweise ein Standard-Plugin-Loader-System im Client, oder Ihr Client wird an die Plugin-Loader-Lösung gekoppelt sein.
Die REST-Zwänge führen zu einem hochgradig skalierbaren System, bei dem die Clients von den Implementierungen der Dienste entkoppelt sind. So können die Clients wiederverwendbar sein, allgemein wie die Browser im Web. Die Clients und die Dienste nutzen dieselben Standards und Vokabeln, so dass sie sich gegenseitig verstehen können, obwohl der Client die Implementierungsdetails des Dienstes nicht kennt. Dies ermöglicht die Entwicklung automatisierter Clients, die REST-Dienste finden und nutzen können, um ihre Ziele zu erreichen. Langfristig können diese Clients miteinander kommunizieren und sich gegenseitig Aufgaben anvertrauen, genau wie Menschen es tun. Wenn wir solche Clients mit Lernmustern versehen, wird das Ergebnis eine oder mehrere KI sein, die das Netz der Maschinen anstelle eines einzelnen Serverparks nutzt. So wird am Ende der Traum von Berners Lee, das semantische Web und die künstliche Intelligenz, Wirklichkeit werden. Im Jahr 2030 werden wir also von Skynet terminiert. Bis dahin ... ;-)
RESTful (Representational State Transfer) API-Programmierung ist das Schreiben von Webanwendungen in einer beliebigen Programmiersprache durch Befolgen von 5 grundlegenden Software Baustil Grundsätze:
- Ressource (Daten, Informationen).
- Eindeutige globale Kennung (alle Ressourcen sind eindeutig gekennzeichnet durch URI ).
- Einheitliche Schnittstelle - einfache und standardisierte Schnittstelle (HTTP) verwenden.
- Repräsentation - die gesamte Kommunikation erfolgt durch Repräsentation (z. B. XML / JSON )
- Zustandslos (jede Anfrage erfolgt in völliger Isolation, es ist einfacher, sie zwischenzuspeichern und die Last auszugleichen),
Mit anderen Worten: Sie schreiben einfache Punkt-zu-Punkt-Netzwerkanwendungen über HTTP, die Verben wie GET, POST, PUT oder DELETE verwenden, indem Sie eine RESTful-Architektur implementieren, die eine Standardisierung der Schnittstelle vorschlägt, die jede "Ressource" offenlegt. Es ist nichts anderes als die Nutzung aktueller Funktionen des Webs auf einfache und effektive Weise (sehr erfolgreiche, bewährte und verteilte Architektur). Es ist eine Alternative zu komplexeren Mechanismen wie SOAP , CORBA y RPC .
Die RESTful-Programmierung entspricht dem Design der Web-Architektur und ermöglicht es Ihnen, bei richtiger Implementierung die Vorteile einer skalierbaren Web-Infrastruktur voll auszuschöpfen.
Hier ist mein grundlegender Überblick über REST. Ich habe versucht, die Denkweise hinter jeder der Komponenten in einer RESTful-Architektur zu demonstrieren, damit das Konzept intuitiver verstanden wird. Hoffentlich hilft dies, REST für einige Leute zu entmystifizieren!
REST (Representational State Transfer) ist eine Entwurfsarchitektur, die beschreibt, wie vernetzte Ressourcen (d. h. Knoten, die Informationen austauschen) entworfen und angesprochen werden. Im Allgemeinen sorgt eine RESTful-Architektur dafür, dass der Client (der anfragende Rechner) und der Server (der antwortende Rechner) Daten lesen, schreiben und aktualisieren können, ohne dass der Client wissen muss, wie der Server arbeitet, und der Server kann sie zurückgeben, ohne etwas über den Client wissen zu müssen. Okay, cool...aber wie machen wir das in der Praxis?
-
Die offensichtlichste Anforderung ist, dass es eine Art universelle Sprache geben muss, damit der Server dem Client mitteilen kann, was er mit der Anfrage zu tun versucht, und damit der Server antworten kann.
-
Um jedoch eine beliebige Ressource zu finden und dem Kunden mitzuteilen, wo sich diese Ressource befindet, muss es eine universelle Möglichkeit geben, auf Ressourcen hinzuweisen. Hier kommen die Universal Resource Identifiers (URIs) ins Spiel; sie sind im Grunde genommen eindeutige Adressen zum Auffinden von Ressourcen.
Aber die REST-Architektur ist damit noch nicht zu Ende! Die obigen Ausführungen erfüllen zwar die grundlegenden Anforderungen, aber wir wollen auch eine Architektur, die ein hohes Verkehrsaufkommen unterstützt, da ein bestimmter Server in der Regel Antworten von einer Vielzahl von Clients verarbeitet. Daher wollen wir den Server nicht überfordern, indem wir ihn dazu bringen, sich Informationen über frühere Anfragen zu merken.
-
Daher legen wir die Einschränkung fest, dass jedes Anfrage-Antwort-Paar zwischen dem Client und dem Server unabhängig ist, d. h. der Server muss sich nicht an frühere Anfragen (frühere Zustände der Client-Server-Interaktion) erinnern, um auf eine neue Anfrage zu antworten. Dies bedeutet, dass unsere Interaktionen zustandslos sein sollen.
-
Um die Belastung unseres Servers durch die Wiederholung von Berechnungen, die bereits für einen bestimmten Kunden durchgeführt wurden, weiter zu verringern, ermöglicht REST auch die Zwischenspeicherung. Grundsätzlich bedeutet Caching, dass ein Schnappschuss der ursprünglichen Antwort an den Client erstellt wird. Wenn der Kunde dieselbe Anfrage erneut stellt, kann der Server dem Kunden den Schnappschuss zur Verfügung stellen, anstatt alle Berechnungen, die zur Erstellung der ursprünglichen Antwort erforderlich waren, erneut durchzuführen. Da es sich jedoch um einen Schnappschuss handelt, sieht der Client die Aktualisierungen erst, wenn der Schnappschuss noch nicht abgelaufen ist - der Server legt im Voraus eine Verfallszeit fest - und die Antwort seit dem ursprünglichen Cache aktualisiert wurde (d. h. die Anfrage würde eine andere Antwort als die im Cache gespeicherte Antwort ergeben), bis der Cache abläuft (oder der Cache gelöscht wird) und die Antwort von Grund auf neu gerendert wird.
-
Die letzte Sache, die Sie oft über RESTful-Architekturen hören werden, ist, dass sie geschichtet sind. Wir haben diese Anforderung bereits implizit in unserer Diskussion über die Interaktion zwischen Client und Server erörtert. Im Grunde bedeutet dies, dass jede Schicht in unserem System nur mit den angrenzenden Schichten interagiert. In unserer Diskussion interagiert also die Client-Schicht mit unserer Server-Schicht (und umgekehrt), aber es kann andere Server-Schichten geben, die dem primären Server bei der Bearbeitung einer Anfrage helfen, mit der der Client nicht direkt kommuniziert. Vielmehr gibt der Server die Anfrage bei Bedarf weiter.
Wenn Ihnen das alles bekannt vorkommt, dann ist das großartig. Das Hypertext Transfer Protocol (HTTP), das das Kommunikationsprotokoll über das World Wide Web definiert, ist eine Implementierung des abstrakten Begriffs der RESTful-Architektur (oder eine Implementierung der abstrakten REST-Klasse, wenn Sie ein OOP-Fanatiker wie ich sind). Bei dieser Implementierung von REST interagieren Client und Server über GET, POST, PUT, DELETE usw., die Teil der universellen Sprache sind, und die Ressourcen können über URLs angegeben werden.
3 Stimmen
Siehe auch die Antwort unter dem folgenden Link stackoverflow.com/a/37683965/3762855
4 Stimmen
REST ist vielleicht ein bisschen alt geworden ;) youtu.be/WQLzZf34FJ8
1 Stimmen
Weitere Informationen finden Sie unter folgendem Link news.ycombinator.com/item?id=3538585
0 Stimmen
Berichtigungen der akzeptierten Antwort hier. stackoverflow.com/questions/19843480/ Oder hier roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven Oder hier web.archive.org/web/20130116005443/http://tomayko.com/writings/
0 Stimmen
Ich möchte nur einen Satz hinzufügen, von dem ich wirklich glaube, dass er viel Bedeutung hat: "Bei REST geht es darum, die Art und Weise, wie das menschliche Web funktioniert, auf das programmatische WEB anzuwenden."
0 Stimmen
RESTful Programmierung (rpc Rahmen) ist eine beliebte, aber nicht beste rpc Rahmen. Http POST und json rpc framework ist besser als REST rpc framework. Welche Methode sollte ich verwenden, wenn ich eine Login-Api hinzufügen möchte? GET?POST? Sollte ich json im POST-Body verwenden oder sollte ich http-Abfrage im POST-Body verwenden? Wie parse ich einen REST-Antwortkörper? Wird der Server json verwenden? Verwendet der Server eine http-Abfrage? REST macht die Dinge nur komplex und nicht konsistent. Ich kann nur POST und json verwenden, um zu tun, was ich will. Ich möchte nicht über GET/POST/DELETE Zeug kümmern.
0 Stimmen
Mark Knol, die Verwendung von Humor oder anderen menschlichen Verhaltensweisen (wie z.B. "Danke" sagen) ist von den Moderatoren, die einen Demutseinlauf erlebt haben, strengstens untersagt.
0 Stimmen
Diese Frage entspricht nicht den Richtlinien von StackOverflow. Sie kann mit einer einfachen Suche beantwortet werden: de.wikipedia.org/wiki/Repräsentative_Zustandsübertragung
9 Stimmen
@OLIVER.KOO Gute Beobachtung. Es ist nur so, dass ich die Frage zu einer Zeit gestellt habe, als das Thema noch recht neu war. Es wurde viel darüber geredet, aber nicht viele Leute wussten, worum es ging. Zumindest wusste ich es nicht, und es scheint, dass meine Frage ihnen geholfen hat, weil sie es auch wissen wollten.