In was bestehen Missverständnisse über die "REST" - Wort und seine Bedeutung
Ist es nicht immer leicht herauszufinden, was wirklich einen Erholsamen Anwendung und/oder der api, denn es ist eine Art von Missverständnis über den REpresentational State Transfer Architekturstil Bedeutung und Bereiche.
Anfangs war ich ziemlich in Schwierigkeiten, was das Adjektiv "Gegenständlich" der Akronym REST, bezeichnet. Das war, weil "representational state" Klang für mich nicht so gut..
Weiter, ich war beeindruckt, auch von einem blog-post der Autor dieses architektonischen Stils, Roy Fielding, wo er viele enttäuscht über die häufige misunderstading, dass die api basiert auf http-Verben Erholsamen, insbesondere hat er die Beschwerden über die Kopplung zwischen client und server diese api in Bezug auf Ihre Namen und Daten Strukturen.
blog-post Referenz: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Möchte ich zu geben versuchen, nur ein theoric Erklärung über REST-arch. Stil, und ich würde gerne wissen, andere Sichtweisen.
InformationsquelleAutor Ciro Corvino | 2016-06-07
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ersten Teil
Mein Ziel ist es, das Augenmerk auf die Grund für den Namen "representational state transfer".
Ich denke, dass die meisten misundertandings über den REST geht unter dem Adjektiv "gegenständlich".
Die meisten Menschen denken, dass "representational" - Wort bezieht sich auf den Ressourcen-Zustand und so baut Anwendung mit Schwerpunkt auf Objekt-Strukturen zur Kommunikation/übertragung zu dem anrufenden Kunden.. aber ich denke, dass der Fokus der "transfer", es ist die übertragung zu"gegenständlich", und so ist es wichtig, die design-Applikationen (oder api), die "gegenständlichen" Fähigkeit des REST-Netzwerk-system, auf das Sie sich verlassen, zu unterstützen-transfers zwischen client-server-Komponenten.
Um herauszufinden, die ganze Frage über die Anliegen der REST-Architektur, die es braucht, um zu verstehen, dass der Autor, Roy Fielding, suggeriert in seiner dissertation eine Reihe von architektonischen Prinzipien zu bauen Architekturen basierend auf den hipertext oder hipermedia Paradigma und das Paradigma ist der zentrale Schlüssel zum verstehen dieses wichtige Thema.
Hinter dem Stil der Organisation einer client-server-Anwendung-Architektur vorgeschlagen, die von Roy Fielding, ich denke, es ist eine bestimmte Vorstellung von einem modernen client-server-Anwendung, die darin besteht, durch eine Art Motor zu Regeln Anwendung Zustandsübergang, dessen Staaten sind, potentiell erweiterbar und unendlich ist.
In dieser vision, die Ipertext\Ipermedia ist das Zentrum des ganzen architektonischen Stil vorgeschlagen von Fielding und das key-Konzept ermöglicht es, dieses Paradigma zu arbeiten, ist die "gegenständliche (Staat) übertragen".
So können wir verstehen, warum das Wort "gegenständlich" bezieht sich auf das Konzept über das "transfer", anstatt das Konzept zu "Staat". Denn es ist die übertragung zu gegenständlich (representational Art), und dies bedeutet, dass es ist das system, verwaltet die "transfers" und auf die stützt sich der client-server-Interaktion, zu geben, einige standard-Hinweise auf die Vertretung, das ist das media-Art-Konzept (oder MIME in die web-Umsetzung der REST), und das ist, meiner Meinung nach, die Hauptursache der name "Representational State Transfer".
So, die Gestaltung einer Erholsamen Anwendung, es ist design zuerst eine Architektur basiert auf web-components, jeder von Ihnen comunicates mit anderen in einer client-server-layered-Architektur-Modell, das senden jeder von Ihnen eine Darstellung Ihres Staates.
Und so, die front-end, die erste Kunde von dieser Architektur werden die Transite durch Ihre Staaten zeigt rapresentation der Staaten sended durch die Komponente oder Komponenten, es fordert befürworten, auf eine einheitliche, konsistente Schnittstelle und nicht auf eine "private" api.
Einer solchen Art von Anwendung, in den Geist des Autors, potenziell erweiterbar auf unendlich Staaten, weil seine Staaten verlassen Sie sich nicht auf ein eigenes api, sondern hängen auf einem univoque system identifier (URI), die gemeinsam von allen Akteuren in dieser Architektur auf ein paar einige Verben zu verwalten transion der Staaten und die vereinbarten gemeinsamen representational transfer system, oder plus.
Diesem übergang endet die Kommunikation mit seiner Darstellung an die genannten server-Komponente, über die Verben, aus denen die "öffentlichen" - api, die sollte gehören zu den stateless-Kommunikation-Protokoll, das die client-server-Komponenten.
So, in diesem client-server-Komponenten-Interaktion besteht in der abwechselnden (übertragung, Kommunikation) von standardisierten Darstellungen (Medien-Typen) von Komponenten Mitgliedstaaten, basierend auf der Verwendung von ein zustandsloses Protokoll ist.
Und das core-Konzept, das all diese Architekturen, um potenziell erstrecken sich unendliche ist die Entkopplung der Komponente Ressourcen, die Strukturen und die Namen mit Ihrer client-Identifikation und Repräsentation (representational transfer).
Zweiten Teil
weitere details auf der mediatype-und RESTful-application-building -
Ich denke, dass die ursprüngliche intuition der Fielding wurde die Idee, dass eine zentrale Funktion, um eine vollständige Entkopplung zwischen client-und server-Komponenten in einer verteilten Anwendungsarchitektur und unbegrenzt erweiterbar ist, wurde die definition einer offenen und sich entwickelnden standard-Darstellungen, und damit die Fähigkeit, diese Komponenten zu tauschen Darstellungen und im Falle des Kunden, um Sie zu interpretieren.
Deshalb "representational transfer"!
Nämlich, transfers basierend auf standardisierten rappresentations.
Stattdessen "Staat" ist genau das, was repräsentiert wird, in die übliche Weise, denn es wird von jedem verstanden-client-Komponente, unterstützt die REST-Prinzipien, und ermöglicht die Darstellung selbst zu sein, der Motor der die Zustandsübergänge enthält in seiner mediatype Darstellung auch der standard-Umgang mit Informationen, die Sie sollten sich auf einen kleinen Satz von standard-Verben, die im Zusammenhang mit der client-server-Kommunikation-Protokoll.
Daher, um Anwendungen zu erstellen (oder die Anschlüsse aus der Sicht von REST) die Einhaltung der standard-REST und daher Erholsamen, bedeutet:
entwerfen uri eigene Mittel;
machen diese uri-immer verfügbar in Darstellungen, sended zu den Kunden;
Schwerpunkt in der Gestaltung die am besten geeigneten Medien geben zusagen zur Unterstützung der eigenen Abläufe, und so ist die gleiche Zustandsübergänge.
Dieser Mittel für die Unterstützung jeder Art von Medien, die auf jeder Art von Gerät und unterstützen auch jede Art von Interaktion, system-oder Transformationsländern (z.B. automatisierte Systeme, die nicht nur Benutzer)
Noch nicht downvoted, aber ich finde diese Erklärung ziemlich rekursive und repetitiv. Sie gehen über '"gegenständlich" und bezieht sich auf Staat,', ohne scheinbar jemals in eine wirklich gute Erklärung, was das wirklich bedeutet... Just my 2€¢.
Vielleicht haben Sie nicht Lesen Sie meine Erklärung, wie Sie behaupten, dass ich "gehen auf die gegenständliche Bezugnahme auf Zustand".. ich sage, dass die gegenständliche bezieht sich auf den transfer.. es wäre besser, wenn Sie Lesen, bevor Sie "konstruktiv" kommentieren. Danke
Ich habe es gelesen und das ist, was ich kam mit. Ihre kühnen Abschnitt in den ersten Absatz und das Fett in der Mitte im wesentlichen wiederholen die gleichen Informationen... ich hatte versucht, lassen Sie Konstruktive Kritik haben, lassen Sie es, wenn Sie es nicht mögen.
Vielen Dank für Eure Vorschläge, ich halte Sie für eine überarbeitung meines posts.. aber ich bestehe darauf, wenn Sie feststellen, dass ich sagte, dass die gegenständliche bezieht sich auf Staat, Sie sind falsch, und viel.. weil das Hauptmotiv schob mich zu diesem Beitrag schreiben, ist es genau diese falsche Annahme.. weitere, die zweite Fett Abschnitt, was in den ersten Fett.. wenn du meinen post gelesen und einen Kommentar über den wirklichen Inhalt, ich würde es zu schätzen wissen eine Menge
InformationsquelleAutor Ciro Corvino
Obwohl ich denke, dass der post ist offensichtlich besser geeignet für Programmierer, dies ist ein allgemeiner Begriff, die Diskussion, ich werde versuchen und geben Sie ihm einen Schuss.
Mir, der REST ist ein transfer des Staates oder der aktuellen Daten, die in eine bestimmte Ressource von einem server zu einem client oder Umgekehrt. Diese übertragung wird vom client initiiert durch die Anrufung bestimmter Operationen, die zugrunde liegenden Kommunikations-Protokoll bietet, auf eine Ressource. Die Darstellung Aspekt ist nun die zurückgegeben Stil/Geschmack/Typ des Staates/der Daten. Wenn ein client so etwas wie
Accept: "application/hal+json", "application/json", "text/html"
es direkt den server auffordern, für die eine Vertretung des Landes in einem der drei Formate (mit Vorliebe auf den führenden) und der server kann entscheiden, basierend auf seine Fähigkeiten, die man zurückgeben. Bestimmte Gewicht Präferenzen angegeben werden können, auch zur Erhöhung der Wahrscheinlichkeit, dass der server zur Rückgabe dieser Medien-Typ, dann lieber eine andere, allgemeinere.REST durch seine Einfachheit, ist tatsächlich schwer zu realisieren, in der Realität, dazu später mehr. Neben einigen architektonische Einschränkungen Roy Fielding, der angegebene link enthält eine weitere Liste von Dingen, die beachtet werden müssen, um einen Dienst oder eine RESTful API, die zusammengefasst in der folgenden Liste:
Die API beachten sollten und nicht gegen das zugrunde liegende Protokoll. Obwohl es sich bei REST über HTTP die meisten der Zeit, es ist nicht beschränkt auf dieses Protokoll.
Starken Fokus auf die Ressourcen und deren Darstellung durch Medien-Typen.
Kunden sollten nicht über erste Kenntnisse oder Annahmen über die verfügbaren Ressourcen oder deren Zustand zurückgegeben ("getippt" Ressource) in eine API, sondern Sie lernen on-the-fly über ausgestellte ersuchen und analysiert die Antworten. Dies gibt dem server die Möglichkeit sich zu bewegen arround oder umbenennen von Ressourcen leicht, ohne zu brechen eine client-Implementierung.
Insbesondere die Letzte Regel ist gegeben durch Roy Fielding ist oft verletzt durch die Vermietung nicht die client-entdecken Sie Ressourcen wie der Endpunkt wird codiert in der client/Anwendung ausdrücklich. Auch der zurückgegebene Typ ist oft im Voraus zugewiesen. Dies führt zu viel URI-design Verwandte Fragen hier bei StackOverflow als URI benötigt, um die Semantik, um für die Entwickler, setzen Sie Sie in den client.
Aber auch der Medien-Typ ist oft nur zu unterstützen
application/json
oderapplication/xml
obwohl Sie nicht tragen keine Semantik, die auf den tatsächlichen Inhalt. XML wurde besonders entwickelt, um erweiterbar sein, daher das X im Namen. Gibt es bereits zahlreiche spezielle XML-basierte Typen da draußen, schwierige Rahmenbedingungen oft zurück, nurapplication/xml
was bringt Last auf den client zu wissen, was die Antwort semantisch bedeutet.Plain
XML
undJSON
jedoch nicht vermitteln eine Semantik auf den eigentlichen Inhalt oder Regeln zu definieren, die Betreuung der Kunden in Ihrem Verständnis. Sie beschreiben die syntax einer client verwenden können, zu erkennen, welche Elemente eine Antwort enthält, und welche Daten Sie enthalten, nichts mehr, nichts weniger.Atom/RSS-und Json-HAL sind oft empfohlen, zumindest erhöhen Sie die HATEOAS Anforderungen, wie Sie links zu anderen Ressourcen und damit helfen, ein client semantisch zu erfassen, die eine bestimmte Zeichenfolge interpretiert werden als weitere Ressource, die Sie einsetzen können. Obwohl die Kunden noch immer nicht wirklich wissen, welche Daten tatsächlich verarbeitet. Daher spezielle Medientypen entwickelt werden sollten, die Unterstützung der Kunden zu verstehen, was die Daten sind alle über und Sie können verschiedene Geschmacksrichtungen für die gleiche Ressource-Zustand, d.h. ein geben nur einen überblick über die Präsentation auf der Ressourcen-Zustand, während Sie einen anderen Medientyp enthalten den vollständigen Satz von Daten.
Dieser, meiner Meinung nach, led-Fielding auf die folgende Aussage:
Die Sache REST versucht einzuführen, ist eine klare Entkopplung von clients an einen bestimmten API-Satz, wie ein web-browser ist nicht gekoppelt an einen bestimmten web-server. Ein web-browser ist in der Lage zu präsentieren große Anzahl von HTML-Seiten gefüllt mit Bildern oder anderen Medien-Typen, ohne zu brechen. Die Entkopplung wird erreicht, indem man ein client-start von einer Basis-URL und dann entdecken Sie die neuen Möglichkeiten, die über die Interpretation der Antworten. HATEOAS ist daher, was treibt die Kunden Zustand zu ändern, durch folgende links, die vom server auf eine frühere Anfrage. Eine änderung auf der server-Seite wird dadurch nicht Bremsen, die jeder wahre Rest-clients, da Sie nur verwenden, was Sie gelernt haben, aus einer früheren Antwort. Ein client, der erwartet, dass die Ressource X zu loacated in Pfad Y und Zustand Z wird, mit hoher Sicherheit, Pause auf einem server ändern.
Medien-Typen ist, mir die knowledge base von einem client und lehrt Sie, was zu tun mit einem bestimmten Dokument, das Staaten, die von diesem Typ. Ein browser, d.h. es wird das Rendern einer HTMl-Seite, so ist es eigentlich gut lesbar für den Menschen. Es wird auch dynamisch ändern Sie die Darstellung mit JavaScript-code und registriert Ereignisse. Bestimmte heruntergeladene bytes sein könnte als Bild dargestellt, einige interpretiert werden als Videos, während andere Arten könnten erzeugen ein bestimmtes Objekt, mit dem Inhalte (wie z.B. bestimmte video-Player, flash-Player oder-applets).
Den real-world problem ist jetzt: Wie schreibt man diese Medien-Typen, die einem beliebigen client in der Lage ist, wirklich zu verstehen. Durch willkürliche meine ich so etwas wie ein automatisiertes system, das hat keine a-priory Kenntnisse der API oder eine Dienstleistung und hat somit, zu lernen, alles über das Anfrage/Antworten. Als Staat und seine Darstellung kann kommen in vielen verschiedenen Geschmacksrichtungen, Lehre, client, wie die Daten interpretiert werden sollen, ist die schwierige Sache. Semantische Verarbeitung von Daten ist immer noch ein großes Forschungs-Feld. Ein automatisiertes system muss wissen, dass bestimmte Zeichenfolgen haben einen bestimmten semantischen und dass etwas in einer Vorlage URI von einem server zurückgegeben werden, sollte die Eingabe erfüllt diese semantische.
Einer Liste von mehr oder weniger bekannten, registrierten Medientypen finden Sie unter IANA. Wo möglich, ist es empfehlenswert, eine dieser Arten von Medien (wenn geeignet) zu vermeiden, das Rad neu erfinden alle immer wieder. Gewisse Anwendungsfälle jedoch erfordern möglicherweise ein benutzerdefiniertes format und benötigen so zusätzliche Aufwand (die Projektierung, die Umsetzung und schließlich das registrieren der Medien geben Sie bei der IANA kann einige Zeit dauern).
Als Reaktion auf diese shortcommings viele implementors versuchen Sie, gehen Sie den einfachen Weg und setzen das wissen in den client, das wird dann eng gekoppelt an die API und nicht einfach reagieren und änderungen an der API selbst. Für uns Menschen ist es ziemlich trivial zu begreifen, die Absicht, eine URI, daher bestehen wir auf eine saubere URI-API. Die Nutzer haben bestimmte vor-Annahmen (auf der Grundlage der Benennungs-und Dokumentation), welche die API-fähig ist und damit die RUHE, um ein marketing-Begriff.
Dem Missverständnis viele Menschen dort haben, ist, wie Fielding sagte, dass ein API, das funktioniert auf HTTP als Erholsam. Auch die Richardson maturity model ist nicht besonders hilfreich zu diesem Thema sowie, dass StackOverflow Gemeinschaft behandelt alles, was irgendwie mit der API über HTTP als REST.
InformationsquelleAutor Roman Vottner