Ein architecture-Stil mit dem Namen REST (Representational State Transfer) spricht sich dafür aus, dass Webanwendungen HTTP verwenden sollten, wie es ursprünglich von vorgesehen war. Suchvorgänge sollten GET -Anfragen verwenden. PUT, POST und DELETE-Anforderungen sollten für die -Mutation, das Erstellen und das Löschen verwendet werden.
REST-Befürworter bevorzugen URLs wie
http://myserver.com/catalog/item/1729
für die Architektur von REST sind diese "hübschen URLs" jedoch nicht erforderlich. Eine GET-Anfrage mit einem Parameter
http://myserver.com/catalog?item=1729
ist genauso wie RESTful.
Beachten Sie, dass GET-Anfragen niemals zur Aktualisierung von Informationen verwendet werden sollten. Beispielsweise eine GET-Anforderung zum Hinzufügen eines Artikels zu einem Einkaufswagen
http://myserver.com/addToCart?cart=314159&item=1729
wäre nicht angemessen. GET-Anforderungen sollten idempotent sein. Das heißt, das zweimalige Ausgeben einer Anforderung sollte sich nicht von der einmaligen Ausgabe unterscheiden. Das macht die Anfragen cachefähig. Eine "In den Warenkorb legen" -Anforderung ist nicht idempotent. Durch zweimalige Ausgabe werden zwei Exemplare des Artikels in den Warenkorb gelegt. Eine POST - Anfrage ist in diesem Zusammenhang eindeutig angebracht. Daher benötigt auch eine RESTful-Webanwendung ihren Anteil an POST -Anfragen.
Dies ist dem ausgezeichneten Buch Core JavaServer Faces Buch von David M. Geary entnommen.
REST ist das zugrunde liegende Architekturprinzip des Webs. Das Erstaunliche am Web ist die Tatsache, dass Clients (Browser) und Server auf komplexe Weise interagieren können, ohne dass der Client zuvor etwas über den Server und die darin enthaltenen Ressourcen weiß. Die wichtigste Einschränkung besteht darin, dass sich Server und Client auf das verwendete Medium einigen müssen, was im Fall des Webs HTML.
Für eine API, die den Prinzipien von REST entspricht, muss der Client nichts über die Struktur der API wissen. Der Server muss vielmehr alle Informationen bereitstellen, die der Client für die Interaktion mit dem Dienst benötigt. Ein Beispiel hierfür ist ein HTML-Formular : Der Server gibt den Speicherort der Ressource und die erforderlichen Felder an. Der Browser weiß nicht im Voraus, wo die Informationen übermittelt werden sollen, und er weiß nicht im Voraus, welche Informationen übermittelt werden sollen. Beide Arten von Informationen werden vollständig vom Server bereitgestellt. (Dieses Prinzip heißt HATEOAS: Hypermedia As The Engine Of Anwendungsstatus .)
Wie trifft dies auf HTTP zu und wie kann es in der Praxis umgesetzt werden? HTTP orientiert sich an Verben und Ressourcen. Die zwei Verben im Mainstream-Gebrauch sind GET und POST, von denen ich denke, dass sie jeder erkennen wird. Der HTTP-Standard definiert jedoch mehrere andere wie PUT und DELETE. Diese Verben werden dann gemäß den Anweisungen des Servers auf Ressourcen angewendet.
Angenommen, wir haben eine Benutzerdatenbank, die von einem Webdienst verwaltet wird. Unser Service verwendet ein benutzerdefiniertes Hypermedium auf JSON-Basis, für das wir den Mimetyp application/json+userdb zuweisen (möglicherweise gibt es auch einen application/xml+userdb und application/whatever+userdb - möglicherweise werden viele Medientypen unterstützt). Der Client und der Server wurden beide so programmiert, dass sie dieses Format verstehen, aber sie wissen nichts voneinander. As Roy Fielding weist darauf hin:
Eine REST -API sollte fast den gesamten beschreibenden Aufwand für die Definition des Medientyps (der Medientypen), der zur Darstellung von Ressourcen und zur Steuerung des Anwendungsstatus verwendet wird, oder für die Definition erweiterter Beziehungsnamen und/oder hypertextfähiger Markierungen für verwenden vorhandene Standardmedientypen.
Eine Anfrage für die Basisressource / könnte ungefähr so aussehen:
Anfrage
GET /
Accept: application/json+userdb
Antwort
200 OK
Content-Type: application/json+userdb
{
"version": "1.0",
"links": [
{
"href": "/user",
"rel": "list",
"method": "GET"
},
{
"href": "/user",
"rel": "create",
"method": "POST"
}
]
}
Aus der Beschreibung unserer Medien wissen wir, dass wir Informationen zu verwandten Ressourcen in Abschnitten finden können, die als "Links" bezeichnet werden. Dies wird als Hypermedia-Steuerelemente bezeichnet. In diesem Fall können wir aus einem solchen Abschnitt erkennen, dass wir eine Benutzerliste finden können, indem wir eine weitere Anfrage für /user stellen:
Anfrage
GET /user
Accept: application/json+userdb
Antwort
200 OK
Content-Type: application/json+userdb
{
"users": [
{
"id": 1,
"name": "Emil",
"country: "Sweden",
"links": [
{
"href": "/user/1",
"rel": "self",
"method": "GET"
},
{
"href": "/user/1",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/1",
"rel": "delete",
"method": "DELETE"
}
]
},
{
"id": 2,
"name": "Adam",
"country: "Scotland",
"links": [
{
"href": "/user/2",
"rel": "self",
"method": "GET"
},
{
"href": "/user/2",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/2",
"rel": "delete",
"method": "DELETE"
}
]
}
],
"links": [
{
"href": "/user",
"rel": "create",
"method": "POST"
}
]
}
Aus dieser Antwort können wir viel ablesen. Zum Beispiel wissen wir jetzt, dass wir einen neuen Benutzer erstellen können, indem wir POST auf /user setzen:
Anfrage
POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb
{
"name": "Karl",
"country": "Austria"
}
Antwort
201 Created
Content-Type: application/json+userdb
{
"user": {
"id": 3,
"name": "Karl",
"country": "Austria",
"links": [
{
"href": "/user/3",
"rel": "self",
"method": "GET"
},
{
"href": "/user/3",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/3",
"rel": "delete",
"method": "DELETE"
}
]
},
"links": {
"href": "/user",
"rel": "list",
"method": "GET"
}
}
Wir wissen auch, dass wir vorhandene Daten ändern können:
Anfrage
PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb
{
"name": "Emil",
"country": "Bhutan"
}
Antwort
200 OK
Content-Type: application/json+userdb
{
"user": {
"id": 1,
"name": "Emil",
"country": "Bhutan",
"links": [
{
"href": "/user/1",
"rel": "self",
"method": "GET"
},
{
"href": "/user/1",
"rel": "edit",
"method": "PUT"
},
{
"href": "/user/1",
"rel": "delete",
"method": "DELETE"
}
]
},
"links": {
"href": "/user",
"rel": "list",
"method": "GET"
}
}
Beachten Sie, dass wir unterschiedliche HTTP-Verben verwenden (GET, PUT, POST, DELETE usw.), um diese Ressourcen zu manipulieren, und dass wir das einzige Wissen für den Client voraussetzen Teil ist unsere Mediendefinition.
Weitere Lektüre:
- Die vielen viel besseren Antworten auf dieser Seite.
Wie ich meiner Frau REST erklärt habe .- Wie ich meiner Frau REST erklärt habe .
- Martin Fowlers Gedanken
- Die Paypal-API verfügt über Hypermedia-Steuerelemente
(Diese Antwort wurde häufig kritisiert, weil sie den Punkt verfehlt hatte. Zum größten Teil war dies eine faire Kritik. Was ich ursprünglich beschrieben habe, entsprach eher der Art und Weise, wie REST normalerweise implementiert wurde Vor ein paar Jahren, als ich das zum ersten Mal schrieb, habe ich die Antwort überarbeitet, um die wahre Bedeutung besser darzustellen.)
RESTful Programmieren geht es um:
- ressourcen, die durch einen permanenten Bezeichner identifiziert werden: URIs sind heutzutage die allgegenwärtige Wahl des Bezeichners
- ressourcen, die mit einem allgemeinen Satz von Verben bearbeitet werden: HTTP-Methoden sind der häufigste Fall - der ehrwürdige
Create,Retrieve,Update,Deletewird zuPOST,GET,PUTundDELETE. REST beschränkt sich jedoch nicht nur auf HTTP, sondern ist gerade der am häufigsten verwendete Transport. - die tatsächlich für eine Ressource abgerufene Darstellung hängt von der Anforderung und nicht von der Kennung ab. Verwenden Sie Accept Header, um zu steuern, ob XML, HTTP oder sogar ein Java-Objekt für die Ressource verwendet werden soll
- beibehalten des Zustands im Objekt und Repräsentieren des Zustands in der Darstellung
- darstellung der Beziehungen zwischen Ressourcen in der Darstellung der Ressource: Die Verknüpfungen zwischen Objekten sind direkt in die Darstellung eingebettet
- ressourcendarstellungen beschreiben, wie die Repräsentation verwendet werden kann und unter welchen Umständen sie konsistent verworfen/erneut abgerufen werden sollte: Verwendung von HTTP-Cache-Control-Headern
Der letzte ist wahrscheinlich hinsichtlich der Folgen und der allgemeinen Wirksamkeit von REST am wichtigsten. Im Allgemeinen scheinen sich die meisten RESTful-Diskussionen auf HTTP und dessen Verwendung in einem Browser zu konzentrieren, und was nicht. Ich verstehe, dass R. Fielding den Begriff geprägt hat, als er die Architektur und die Entscheidungen beschrieb, die zu HTTP führen. In seiner Doktorarbeit geht es mehr um die Architektur und Cache-Fähigkeit von Ressourcen als um HTTP.
Wenn Sie wirklich daran interessiert sind, was eine RESTful-Architektur ist und warum sie funktioniert, lesen Sie ein paar Mal seine These und lesen Sie die ganze Sache und nicht nur Kapitel 5! Sehen Sie sich als Nächstes warum DNS funktioniert an. Lesen Sie mehr über die hierarchische Organisation von DNS und die Funktionsweise von Verweisen. Lesen Sie anschließend, wie das DNS-Caching funktioniert. Lesen Sie schließlich die HTTP-Spezifikationen ( RFC2616 und RFC3040 ) und prüfen Sie, wie und warum das Caching so funktioniert, wie es funktioniert. Irgendwann wird es einfach klicken. Die letzte Offenbarung für mich war, als ich die Ähnlichkeit zwischen DNS und HTTP sah. Anschließend beginnt das Klicken, wenn Sie wissen, warum SOA und Message Passing Interfaces skalierbar sind.
Ich denke, dass der wichtigste Trick beim Verständnis der architektonischen Bedeutung und der Auswirkungen auf die Performance von RESTful- und Shared Nothing -Architekturen darin besteht, zu vermeiden, dass die Technologie- und Implementierungsdetails hängen bleiben. Konzentrieren Sie sich darauf, wer Ressourcen besitzt, wer für die Erstellung/Pflege dieser Ressourcen verantwortlich ist usw. Denken Sie dann an Repräsentationen, Protokolle und Technologien.
So könnte es aussehen.
Erstellen Sie einen Benutzer mit drei Eigenschaften:
POST /user
fname=John&lname=Doe&age=25
Der Server antwortet:
200 OK
Location: /user/123
In Zukunft können Sie dann die Benutzerinformationen abrufen:
GET /user/123
Der Server antwortet:
200 OK
<fname>John</fname><lname>Doe</lname><age>25</age>
Um den Datensatz zu ändern (lname und age bleiben unverändert):
PATCH /user/123
fname=Johnny
Um den Datensatz zu aktualisieren (und folglich sind lname und age NULL)
PUT /user/123
fname=Johnny
Ein großartiges Buch über REST ist REST in der Praxis .
Muss gelesen werden sind Representational State Transfer (REST) und REST. APIs müssen hypertextgesteuert sein .
In Martin Fowlers Artikel Richardson Maturity Model (RMM) finden Sie eine Erklärung, was ein RESTful-Service ist.
Um RESTful zu sein, muss ein Service Hypermedia als Engine of Application State erfüllen. (HATEOAS) , dh es muss Level 3 im RMM erreichen. Lesen Sie den Artikel , um Details oder die Folien des qcon talk zu lesen.
Die HATEOAS-Einschränkung ist ein Akronym für Hypermedia als Engine von Anwendungsstatus. Dieses Prinzip lautet das wichtigste Unterscheidungsmerkmal zwischen einem REST und die meisten anderen Formen von Client-Servern System.
...
Ein Client einer RESTful-Anwendung muss kennen nur eine einzige feste URL für den Zugriff auf es. Alle zukünftigen Aktionen sollten .__ sein. dynamisch auffindbar aus Hypermedia-Links in der Darstellungen der Ressourcen, die werden von dieser URL zurückgegeben . Standardisierte Medientypen sind auch erwartet, von jedem verstanden zu werden Client, der möglicherweise eine RESTful-API verwendet. (Aus Wikipedia, der freien Enzyklopädie)
REST Der Litmus-Test für Web-Frameworks ist ein ähnlicher Reifetest für Web-Frameworks.
Annäherung an pure REST: HATEOAS lieben lernen ist eine gute Linksammlung.
REST im Vergleich zu SOAP für die Public Cloud beschreibt die aktuellen Nutzungsniveaus von REST.
REST und Versionierung behandelt Erweiterbarkeit, Versionierung, Evolvability usw. durch Modifizierbarkeit
Was ist REST?
REST steht für Representational State Transfer. (Manchmal wird Buchstabiert "ReST".) Es basiert auf einem zustandslosen Client-Server, der cachefähig ist Kommunikationsprotokoll - und in praktisch allen Fällen das HTTP Protokoll wird verwendet.
REST ist ein Architekturstil zum Entwerfen vernetzter Anwendungen . Die Idee ist, dass, anstatt komplexe Mechanismen wie CORBA zu verwenden, RPC oder SOAP zum Herstellen einer Verbindung zwischen Computern. Für die Erstellung von .__ wird einfaches HTTP verwendet. Anrufe zwischen Maschinen.
In vielerlei Hinsicht kann das auf HTTP basierende World Wide Web selbst angesehen werden als REST-basierte Architektur. RESTful-Anwendungen verwenden HTTP-Anforderungen zum Buchen von Daten (Erstellen und/oder Aktualisieren), Lesen von Daten (z. B. Abfragen stellen), und Daten löschen. Daher verwendet REST HTTP für alle vier CRUD (Erstellen/Lesen/Aktualisieren/Löschen).
REST ist eine einfache Alternative zu Mechanismen wie RPC (Remote Procedure Calls) und Web Services (SOAP, WSDL usw.). Später werden wir Sehen Sie, wie viel einfacher REST ist.
Obwohl es einfach ist, ist REST voll ausgestattet. es gibt im Grunde nichts, was Sie in Web Services tun können, was mit einem RESTful .__ nicht möglich ist. die Architektur. REST ist kein "Standard". Es wird nie ein W3C geben Zum Beispiel für REST empfohlen. Und während es REST gibt Das Programmieren von Frameworks mit REST ist so einfach, dass Sie oft "rollen Sie Ihre eigenen" mit Standard-Bibliotheksfunktionen in Sprachen wie Perl, Java oder C #.
Eine der besten Referenzen, die ich gefunden habe, als ich versuche, die einfache wirkliche Bedeutung von Ruhe zu finden.
REST verwendet die verschiedenen HTTP-Methoden (hauptsächlich GET/PUT/DELETE), um Daten zu bearbeiten.
Anstatt eine bestimmte URL zum Löschen einer Methode zu verwenden (z. B. /user/123/delete), würden Sie eine DELETE-Anforderung an die /user/[id]-URL senden, um einen Benutzer zu bearbeiten und Informationen zu einem Benutzer abzurufen, an den Sie eine GET-Anforderung an /user/[id] senden.
Stattdessen eine Reihe von URLs, die wie folgt aussehen könnten.
GET /delete_user.x?id=123
GET /user/delete
GET /new_user.x
GET /user/new
GET /user?id=1
GET /user/id/1
Sie verwenden die HTTP-Verben und haben ..
GET /user/2
DELETE /user/2
PUT /user
Es ist die Programmierung, bei der die Architektur Ihres Systems zum REST - Stil passt von Roy Fielding in seiner Doktorarbeit entworfen wurde. Da dies der Architekturstil ist, der das Internet (mehr oder weniger) beschreibt, interessieren sich viele Leute dafür.
Bonusantwort: Nein. Wenn Sie die Softwarearchitektur nicht als Akademikerin studieren oder Web-Services entwerfen, gibt es wirklich keinen Grund, den Begriff zu hören.
Ich entschuldige mich, wenn ich die Frage nicht direkt beantworte, aber es ist einfacher, dies anhand detaillierterer Beispiele zu verstehen. Fielding ist aufgrund der Abstraktion und Terminologie nicht leicht zu verstehen.
Es gibt ein ziemlich gutes Beispiel hier:
Erklärung von REST und Hypertext: Spam-E der Spam-Reinigungsroboter
Und noch besser, es gibt hier eine klare Erklärung mit einfachen Beispielen (das PowerPoint ist umfangreicher, aber Sie können das meiste in der HTML-Version erhalten):
http://www.xfront.com/REST.ppt oder http://www.xfront.com/REST.html
Nachdem ich die Beispiele gelesen hatte, konnte ich sehen, warum Ken sagt, dass REST hypertextgesteuert ist. Ich bin nicht wirklich sicher, dass er recht hat, denn/user/123 ist ein URI, der auf eine Ressource verweist, und es ist mir nicht klar, dass es unRESTful ist, nur weil der Client "out-of-band" davon weiß.
Dieses xfront-Dokument erklärt den Unterschied zwischen REST und SOAP. Dies ist auch wirklich hilfreich. Wenn Fielding sagt: " Das ist RPC. Es schreit RPC. ". Es ist klar, dass RPC nicht REST-fähig ist. Daher ist es hilfreich, die genauen Gründe dafür zu finden. (SOAP ist eine Art von RPC.)
Ich würde sagen, bei der REST-Programmierung geht es darum, Systeme (API) zu erstellen, die dem Architekturstil REST folgen.
Ich fand dieses fantastische, kurze und leicht verständliche Tutorial zu REST von Dr. M. Elkstein und zitierte den wesentlichen Teil, der Ihre Frage zum größten Teil beantworten würde:
REST ist ein -Architekturstil zum Entwerfen vernetzter Anwendungen . Die Idee ist, dass, anstatt komplexe Mechanismen wie CORBA zu verwenden, RPC oder SOAP zum Herstellen einer Verbindung zwischen Computern. Für die Erstellung von .__ wird einfaches HTTP verwendet. Anrufe zwischen Maschinen.
- In vielerlei Hinsicht kann das auf HTTP basierende World Wide Web selbst als REST-basierte Architektur betrachtet werden.
RESTful-Anwendungen verwenden HTTP-Anforderungen zum Buchen von Daten (Erstellen und/oder Aktualisieren), Lesen von Daten (z. B. Abfragen stellen) und Löschen von Daten. Somit ist REST verwendet HTTP für alle vier CRUD-Vorgänge (Erstellen/Lesen/Aktualisieren/Löschen).
Ich denke nicht, dass Sie sich dumm fühlen sollten, wenn Sie nicht von REST außerhalb von Stack Overflow hören ... ich wäre in derselben Situation !; Antworten auf diese andere SO - Frage zu Warum wird REST jetzt groß könnte einige Gefühle lindern.
Was ist REST?
REST in offiziellen Worten: REST ist ein Architekturstil, der auf bestimmten Prinzipien auf der Grundlage der aktuellen "Web" -Fundamentaldaten basiert ..__ Es gibt fünf grundlegende Grundlagen des Webs, die zur Erstellung von REST -Diensten genutzt werden.
- Prinzip 1: Alles ist eine Ressource.__Im Architekturstil von REST werden Daten und Funktionalität als Ressourcen betrachtet, auf die mit Hilfe von URIs (Uniform Resource Identifiers), normalerweise Links im Web, zugegriffen wird.
- Prinzip 2: Jede Ressource wird durch einen eindeutigen Bezeichner (URI) identifiziert
- Prinzip 3: Verwenden Sie einfache und einheitliche Schnittstellen
- Grundsatz 4: Kommunikation erfolgt durch Vertretung
- Prinzip 5: Sei staatenlos
Ich sehe eine Reihe von Antworten, die besagen, dass das Setzen von alles über Benutzer 123 an der Ressource "/ user/123" RESTful ist.
Roy Fielding, der den Begriff geprägt hat, sagt REST APIs müssen hypertextgesteuert sein . Insbesondere darf "A REST API keine festen Ressourcennamen oder -hierarchien definieren".
Wenn Ihr "/ user/123" -Pfad auf dem Client hartcodiert ist, ist dies nicht wirklich RESTful. Eine gute Verwendung von HTTP vielleicht vielleicht nicht. Aber nicht RESTful. Es muss aus Hypertext kommen.
Die Antwort ist sehr einfach, es gibt eine Dissertation von Roy Fielding.] 1 In dieser Dissertation definiert er die REST -Prinzipien. Wenn eine Anwendung alle diese Prinzipien erfüllt, handelt es sich um eine Anwendung REST.
Der Begriff RESTful wurde erstellt, weil ppl das Wort REST erschöpft hat, indem er seine Nicht-REST-Anwendung als REST aufrief. 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 Schnittstellenbeschränkung nicht erfüllten.
Die Einschränkungen von REST lauten wie folgt:
client-Server-Architektur
Es funktioniert also beispielsweise nicht mit PUB/SUB-Sockets, sondern basiert auf REQ/REP.
zustandslose Kommunikation
Der Server behält also nicht die Zustände der Clients bei. Dies bedeutet, dass Sie den Server nicht für einen seitlichen Sitzungsspeicher verwenden können und Sie müssen jede Anforderung authentifizieren. Ihre Clients senden möglicherweise grundlegende Authentifizierungs-Header über eine verschlüsselte Verbindung. (Bei großen Anwendungen ist es schwierig, viele Sitzungen zu verwalten.)
verwendung des Cache, wenn Sie können
Sie müssen also nicht immer und immer wieder die gleichen Anforderungen erfüllen.
einheitliche Schnittstelle als gemeinsamer Vertrag zwischen Client und Server
Der Vertrag zwischen dem Client und dem Server wird vom Server nicht gepflegt. Mit anderen Worten, der Client muss von der Implementierung des Dienstes entkoppelt sein. Sie können diesen Status erreichen, indem Sie Standardlösungen wie den IRI (URI) -Standard zum Identifizieren von Ressourcen, den HTTP-Standard für den Nachrichtenaustausch, Standard-MIME-Typen zur Beschreibung des Körperserialisierungsformats, Metadaten (möglicherweise RDF) Vokabeln, Mikroformate, etc.), um die Semantik verschiedener Teile des Nachrichtentexts zu beschreiben. Um die IRI-Struktur vom Client zu entkoppeln, müssen Sie Hyperlinks an die Clients in Hypermedia-Formaten wie HTML, JSON-LD, HAL usw. senden. Ein Client kann also die den Hyperlinks zugewiesenen Metadaten (möglicherweise Linkrelations, RDF - Vokabeln) verwenden, um durch die richtigen Zustandsübergänge durch die Zustandsmaschine der Anwendung zu navigieren, um sein aktuelles Ziel zu erreichen.
Wenn ein Kunde beispielsweise eine Bestellung an einen Webshop senden möchte, muss er die Hyperlinks in den vom Webshop gesendeten Antworten überprüfen. Durch das Überprüfen der Links wird ein Link gefunden, der mit http://schema.org/OrderAction beschrieben wird. Der Client kennt den schema.org-Vokab, so dass er durch die Aktivierung dieses Hyperlinks die Bestellung absendet. Es aktiviert also den Hyperlink und sendet eine
POST https://example.com/api/v1/order-Nachricht mit dem richtigen Körper. Danach verarbeitet der Dienst die Nachricht und antwortet mit dem Ergebnis mit dem richtigen HTTP-Statusheader, z. B.201 - created, mit Erfolg. Zum Annotieren von Nachrichten mit detaillierten Metadaten muss die Standardlösung ein RDF - Format verwenden, zum Beispiel JSON-LD mit einem REST - Vokab, zum Beispiel Hydra und Domäne bestimmte Vokabeln wie schema.org oder jedes andere Linked Data-Vokab und möglicherweise ein benutzerdefiniertes anwendungsspezifisches Vokabular, falls erforderlich. Das ist jetzt nicht einfach. Aus diesem Grund verwenden die meisten ppl HAL- und andere einfache Formate, die normalerweise nur ein REST - Vokabular enthalten, jedoch keine Unterstützung für verknüpfte Daten.erstellen Sie ein Schichtsystem, um die Skalierbarkeit zu erhöhen
Das REST System besteht aus hierarchischen Schichten. Jede Schicht enthält Komponenten, die die Dienste von Komponenten verwenden, die sich in der nächsten darunter liegenden Schicht befinden. So können Sie mühelos neue Layer und Komponenten hinzufügen.
Beispielsweise gibt es eine Clientschicht, die die Clients enthält, und darunter befindet sich eine Serviceebene, die einen einzelnen Service enthält. Jetzt können Sie einen clientseitigen Cache zwischen ihnen hinzufügen. Danach können Sie eine weitere Dienstinstanz und einen Lastenausgleich hinzufügen usw. Der Client- und der Dienstcode werden nicht geändert.
code on Demand zur Erweiterung der Clientfunktionalität
Diese Einschränkung ist optional. Sie können beispielsweise einen Parser für einen bestimmten Medientyp an den Client senden und so weiter. Dazu benötigen Sie möglicherweise ein Standard-Plugin-Loader-System im Client oder Ihr Client wird an die Plugin-Loader-Lösung gekoppelt .
REST-Einschränkungen führen zu einem hoch skalierbaren System, bei dem die Clients von den Implementierungen der Dienste entkoppelt sind. Die Clients können also allgemein wiederverwendbar sein, genau wie die Browser im Web. Die Clients und die Services haben die gleichen Standards und Vokabeln, sodass sie sich verstehen können, obwohl der Client die Implementierungsdetails des Services nicht kennt. Dadurch können automatisierte Clients erstellt werden, die REST -Dienste zum Erreichen ihrer Ziele finden und verwenden können. Langfristig können sich diese Kunden untereinander verständigen und sich bei ihren Aufgaben anvertrauen, so wie Menschen es tun. Wenn wir solchen Clients Lernmuster hinzufügen, wird das Ergebnis eine oder mehrere KI sein, die das Web der Maschinen anstelle eines einzelnen Serverparks verwenden. Am Ende also der Traum von Berners Lee: Das Semantic Web und die künstliche Intelligenz werden Realität sein. Im Jahr 2030 werden wir also vom Skynet beendet. Bis dann ... ;-)
RESTful (Representational State Transfer) Die API-Programmierung schreibt Webapplikationen in jeder Programmiersprache, indem sie 5 grundlegende Software Architekturstil Prinzipien verwendet:
- Ressource (Daten, Informationen).
- Eindeutiger globaler Bezeichner (alle Ressourcen sind eindeutig mit URI gekennzeichnet).
- Einheitliche Schnittstelle - einfache und Standardschnittstelle (HTTP) verwenden.
- Repräsentation - die gesamte Kommunikation erfolgt durch Repräsentation (z. B. XML / JSON )
- Stateless (jede Anforderung wird vollständig isoliert ausgeführt, es ist einfacher zwischenzuspeichern und 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" bereitstellt. Es ist nichts, als die aktuellen Features des Webs einfach und effektiv zu nutzen (sehr erfolgreiche, bewährte und verteilte Architektur). Es ist eine Alternative zu komplexeren Mechanismen wie SOAP , CORBA und RPC .
RESTful-Programmierung entspricht dem Webarchitektur-Design und ermöglicht Ihnen bei ordnungsgemäßer Implementierung den vollen Nutzen der skalierbaren Webinfrastruktur.
Wenn ich die ursprüngliche Dissertation zu REST auf nur 3 kurze Sätze reduzieren musste, denke ich, dass Folgendes das Wesentliche erfasst:
- Ressourcen werden über URLs angefordert.
- Protokolle sind auf das beschränkt, was Sie über URLs kommunizieren können.
- Metadaten werden als Name-Wert-Paare (Post-Daten- und Abfragezeichenfolge-Parameter) übergeben.
Danach ist es leicht, in Debatten über Anpassungen, Kodierungskonventionen und bewährte Verfahren zu geraten.
Interessanterweise werden in der Dissertation keine HTTP POST-, GET-, DELETE- oder PUT-Operationen erwähnt. Dies muss die spätere Interpretation einer "Best Practice" für eine "einheitliche Schnittstelle" sein.
In Bezug auf Web-Services scheint es so, als müssten wir WSDL- und SOAP -basierte Architekturen unterscheiden, die die Schnittstelle mit erheblichem Aufwand und möglicherweise unnötiger Komplexität belasten. Sie erfordern außerdem zusätzliche Frameworks und Entwicklerwerkzeuge für die Implementierung. Ich bin mir nicht sicher, ob REST der beste Ausdruck ist, um zwischen Common-Sense-Schnittstellen und übermäßig konstruierten Schnittstellen wie WSDL und SOAP zu unterscheiden. Aber wir brauchen etwas.
Hier ist mein grundlegender Überblick über REST. Ich habe versucht, die Hintergründe jeder Komponente in einer RESTful-Architektur zu veranschaulichen, sodass das Verständnis des Konzepts intuitiver ist. Hoffentlich hilft das bei der Entmystifizierung REST für manche Leute!
REST (Representational State Transfer) ist eine Entwurfsarchitektur, die beschreibt, wie vernetzte Ressourcen (d. H. Knoten, die Informationen gemeinsam nutzen) entworfen und angesprochen werden. Eine RESTful-Architektur macht es im Allgemeinen so, dass der Client (die anfragende Maschine) und der Server (die antwortende Maschine) Daten zum Lesen, Schreiben und Aktualisieren von Daten anfordern können, ohne dass der Client wissen muss, wie der Server arbeitet und der Server übergeben kann es zurück, ohne etwas über den Kunden wissen zu müssen. Okay, cool ... aber wie machen wir das in der Praxis?
Die offensichtlichste Anforderung ist, dass es eine universelle Sprache geben muss, damit der Server dem Client mitteilen kann, was er mit der Anforderung zu tun versucht und der Server antworten soll.
Um jedoch eine bestimmte Ressource zu finden und dem Kunden dann mitzuteilen, wo diese Ressource lebt, muss es einen universellen Weg geben, auf Ressourcen zu zeigen. Hier kommen Universal Resource Identifiers (URIs) ins Spiel. Sie sind im Wesentlichen eindeutige Adressen, um die Ressourcen zu finden.
Aber die REST Architektur endet nicht dort! Während das Vorstehende die grundlegenden Anforderungen erfüllt, die wir wollen, möchten wir auch eine Architektur haben, die den Datenverkehr mit hohem Volumen unterstützt, da jeder Server normalerweise Antworten von einer Reihe von Clients verarbeitet. Daher möchten wir den Server nicht überfordern, indem er sich Informationen über vorherige Anfragen speichert.
Daher haben wir die Einschränkung, dass jedes Anfrage-Antwort-Paar zwischen dem Client und dem Server unabhängig ist. Dies bedeutet, dass sich der Server nicht an frühere Anforderungen (vorherige Zustände der Client-Server-Interaktion) erinnern muss, um auf eine neue Antwort zu antworten anfordern. Das heißt, wir wollen, dass unsere Interaktionen zustandslos sind.
Um die Belastung unseres Servers durch das Wiederholen von Berechnungen, die kürzlich für einen bestimmten Client bereits durchgeführt wurden, weiter zu reduzieren, ermöglicht REST auch das Zwischenspeichern. Unter Zwischenspeicherung wird im Wesentlichen eine Momentaufnahme der an den Client gelieferten ersten Antwort erstellt. Wenn der Client dieselbe Anforderung erneut stellt, kann der Server dem Client den Snapshot zur Verfügung stellen, anstatt alle erforderlichen Berechnungen durchzuführen, um die erste Antwort zu erstellen. Da es sich jedoch um eine Momentaufnahme handelt, wenn die Momentaufnahme nicht abgelaufen ist, legt der Server eine Ablaufzeit im Voraus fest und die Antwort wurde seit dem ersten Cache aktualisiert (dh die Anfrage würde eine andere Antwort geben als die zwischengespeicherte Antwort). Der Client sieht die Aktualisierungen erst, wenn der Cache abläuft (oder der Cache gelöscht wurde) und die Antwort erneut von Grund auf dargestellt wird.
Das Letzte, was Sie bei RESTful-Architekturen häufig hier machen, ist, dass sie mehrschichtig sind. Wir haben diese Anforderung bereits implizit in der Diskussion der Interaktion zwischen Client und Server diskutiert. Im Grunde bedeutet dies, dass jede Schicht in unserem System nur mit benachbarten Schichten interagiert. In unserer Diskussion interagiert die Clientschicht mit unserer Serverschicht (und umgekehrt), es können jedoch andere Serverschichten vorhanden sein, die dem Primärserver dabei helfen, eine Anforderung zu verarbeiten, mit der der Client nicht direkt kommuniziert. Der Server leitet die Anforderung vielmehr bei Bedarf weiter.
Wenn das alles bekannt klingt, dann ist es 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 einer Instanz der REST Klasse, falls Sie eine OOP Fanatiker wie ich). Bei dieser Implementierung von REST interagieren Client und Server über GET, POST, PUT, DELETE usw., die Teil der Universalsprache sind, und auf die Ressourcen kann über URLs verwiesen werden.
REST ist ein architektonisches Muster und ein Stil zum Schreiben verteilter Anwendungen. Es ist kein Programmierstil im engeren Sinne.
Wenn Sie sagen, dass Sie den Stil REST verwenden, ähnelt das der Feststellung, dass Sie ein Haus in einem bestimmten Stil gebaut haben, z. Sowohl REST als Softwarestil als auch Tudor oder Victorian als Heimstil können durch die Qualitäten und Einschränkungen definiert werden, aus denen sie bestehen. Beispielsweise muss REST über eine Client Server-Trennung verfügen, bei der die Nachrichten selbstbeschreibend sind. Häuser im Tudor-Stil haben überlappende Giebel und Dächer, die steil nach vorne ausgerichtet sind. Sie können Roys Dissertation lesen, um mehr über die Einschränkungen und Qualitäten von REST zu erfahren.
Im Gegensatz zu den Home-Styles hat REST es schwer gehabt, konsequent und praktisch angewendet zu werden. Dies kann beabsichtigt gewesen sein. Die tatsächliche Implementierung bleibt dem Designer überlassen. Sie können also das tun, was Sie möchten, solange Sie die Einschränkungen der von Ihnen erstellten Dissertation REST -Systeme erfüllen.
Bonus:
Das gesamte Web basiert auf REST (oder REST basierte auf dem Web). Als Webentwickler möchten Sie dies vielleicht wissen, obwohl Sie nicht unbedingt gute Web-Apps schreiben müssen.
Ich denke, der Punkt des Erholens ist die Trennung der Statefulness in eine höhere Schicht, wobei das Internet (Protokoll) als zustandslose Transportschicht genutzt wird. Die meisten anderen Ansätze vermischen die Dinge.
Es war der beste praktische Ansatz, um mit den grundlegenden Änderungen der Programmierung im Internet-Zeitalter umzugehen. Zu den grundlegenden Änderungen hat Erik Meijer hier eine Diskussion gezeigt: http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197 . Er fasst es als die fünf Effekte zusammen und präsentiert eine Lösung, indem er die Lösung in einer Programmiersprache gestaltet. Die Lösung kann unabhängig von der Sprache auch auf Plattform- oder Systemebene erreicht werden. Das Erholsame könnte als eine der Lösungen angesehen werden, die in der gegenwärtigen Praxis sehr erfolgreich waren.
Mit einem ruhigen Stil können Sie den Status der Anwendung über ein unzuverlässiges Internet abrufen und bearbeiten. Wenn der aktuelle Vorgang beim Abrufen des korrekten und aktuellen Status fehlschlägt, muss der Principal für die Null-Validierung verwendet werden, damit die Anwendung weiterlaufen kann. Wenn es nicht möglich ist, den Status zu bearbeiten, verwendet es normalerweise mehrere Bestätigungsstufen, um die Dinge korrekt zu halten. In diesem Sinne ist Rest nicht eine vollständige Lösung, sondern benötigt die Funktionen in einem anderen Teil des Webanwendungsstapels, um dessen Funktion zu unterstützen.
Aus dieser Sicht ist der Reststil nicht wirklich an das Internet oder die Webanwendung gebunden. Dies ist eine grundlegende Lösung für viele Programmiersituationen. Es ist auch nicht einfach, es macht die Benutzeroberfläche wirklich einfach und kommt mit anderen Technologien erstaunlich gut zurecht.
Nur mein 2c.
Edit: Zwei weitere wichtige Aspekte:
Staatenlosigkeit ist irreführend. Es geht um die restful API, nicht um die Anwendung oder das System. Das System muss stateful sein. Beim restful Design geht es darum, ein Stateful-System basierend auf einer zustandslosen API zu entwerfen. Einige Zitate aus einer anderen QA :
- REST arbeitet mit Ressourcendarstellungen, die jeweils durch eine URL identifiziert werden. Dies sind normalerweise keine Datenobjekte, sondern Abstraktionen von komplexen Objekten.
- REST steht für "Representational State Transfer" (Repräsentativer Zustandstransfer). Dies bedeutet, dass es nur darum geht, den Zustand einer Ressource in einem System zu kommunizieren und zu ändern.
Dies ist eine erstaunlich lange "Diskussion" und doch recht verwirrend, um es gelinde auszudrücken.
IMO:
1) Es gibt kein ruhiges Programmieren ohne großen Joint und viel Bier :)
2) Representational State Transfer (REST) ist ein Architekturstil, der in der Dissertation von Roy Fielding ..__ spezifiziert ist und eine Reihe von Einschränkungen aufweist. Wenn Ihr Service/Kunde diese respektiert, ist dies RESTful. Das ist es.
Sie können die Einschränkungen (signifikant) zusammenfassen auf:
- zustandslose Kommunikation
- respektieren Sie die HTTP-Spezifikationen (wenn HTTP verwendet wird)
- kommuniziert klar die übertragenen Inhaltsformate
- verwenden Sie Hypermedia als Engine des Anwendungsstatus
Es gibt einen anderen sehr guten Beitrag , der die Dinge schön erklärt.
Viele Antworten kopierten/fügten gültige Informationen ein, mischten sie und fügten einige Verwirrung hinzu. Die Leute reden hier über Level, über RESTFul-URIs (so etwas gibt es nicht!), Wenden die HTTP-Methoden GET, POST, PUT ... an REST geht es nicht oder nicht nur darum.
Zum Beispiel Links - es ist schön, eine schön aussehende API zu haben, aber am Ende kümmert sich der Client/Server nicht wirklich um die Links, die Sie erhalten/senden. Es ist der Inhalt, der zählt.
Am Ende sollte jeder RESTful-Client in der Lage sein, einen beliebigen RESTful-Service zu nutzen, solange das Inhaltsformat bekannt ist.
Alte Frage, neue Art zu antworten. Es gibt eine Menge Missverständnisse über dieses Konzept. Ich versuche mich immer zu erinnern:
- Strukturierte URLs und HTTP-Methoden/Verben sind nicht die Definition einer erholsamen Programmierung.
- JSON ist keine erholsame Programmierung
- RESTful Programming ist nicht für APIs
Ich definiere ruhiges Programmieren als
Eine Anwendung ist erholsam, wenn sie Ressourcen (die Kombination aus Daten- und Statusübergangskontrollen) in einem Medientyp bereitstellt, den der Client versteht
Um ein ruhiger Programmierer zu sein, müssen Sie versuchen, Anwendungen zu erstellen, mit denen Schauspieler Dinge tun können. Nicht nur die Datenbank verfügbar machen.
Statusübergangskontrollen sind nur sinnvoll, wenn Client und Server eine Medientypdarstellung der Ressource vereinbaren. Ansonsten gibt es keine Möglichkeit zu wissen, was ein Steuerelement ist und was nicht und wie ein Steuerelement ausgeführt wird. IE wenn Browser nicht wussten <form> Tags in HTML, dann gäbe es nichts, was Sie in Ihrem Browser in den Übergangszustand versetzen könnten.
Ich möchte nicht für mich selbst werben, aber ich gehe in meinem Vortrag ausführlich auf diese Ideen ein http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html) .
Ein Auszug aus meinem Vortrag handelt von dem oft erwähnten Richardson-Reifegradmodell. Ich glaube nicht an die Levels. Entweder bist du RESTful (Level 3) oder du bist es nicht tut für Sie auf dem Weg zu RESTful
REST === HTTP Analogie ist nicht korrekt, bis Sie nicht auf die Tatsache betonen, dass es „Muss“ sein _ _ hateoas angetrieben.
Roy selbst hat es geklärt hier .
Eine REST - API sollte ohne Vorkenntnisse außerhalb der ursprünglichen URI (Lesezeichen) und einer Reihe standardisierter Medientypen eingegeben werden, die für die beabsichtigte Zielgruppe geeignet sind (dh von jedem Client, der die API verwendet, verstanden wird). . Ab diesem Zeitpunkt müssen alle Anwendungszustandsübergänge durch die Clientauswahl der vom Server bereitgestellten Auswahlmöglichkeiten gesteuert werden, die in den empfangenen Repräsentationen vorhanden sind oder durch die Manipulation der Repräsentationen durch den Benutzer impliziert werden. Die Übergänge können durch das Wissen des Kunden über Medientypen und Ressourcenkommunikationsmechanismen bestimmt (oder eingeschränkt) werden, wobei beide im laufenden Betrieb verbessert werden können (z. B. Code-on-Demand).
[Misserfolg hier bedeutet, dass Out-of-Band-Informationen anstelle von Hypertext die Interaktion antreiben.]
RESTist ein Architekturstil, der auf Webstandards und dem HTTP-Protokoll (eingeführt im Jahr 2000) basiert.
In einer REST - basierten Architektur ist alles eine Ressource (Benutzer, Aufträge, Kommentare). Auf eine Ressource wird über eine allgemeine Schnittstelle zugegriffen, die auf den HTTP-Standardmethoden (GET, PUT, PATCH, DELETE usw.) basiert.
In einer auf REST basierenden Architektur haben Sie einen REST -Server, der .__ bereitstellt. Zugang zu den Ressourcen. Ein REST - Client kann auf den REST .__ zugreifen und ihn ändern. Ressourcen.
Jede Ressource sollte die allgemeinen HTTP-Vorgänge unterstützen. Ressourcen werden durch globale IDs identifiziert (dies sind normalerweise URIs).
REST ermöglicht, dass Ressourcen unterschiedliche Repräsentationen haben, z. B. Text, XML, JSON usw. Der Client REST kann über das HTTP-Protokoll nach einer bestimmten Repräsentation fragen (Inhaltsverhandlung).
HTTP-Methoden:
Die Methoden PUT, GET, POST und DELETE werden typischerweise in REST - basierten Architekturen verwendet. Die folgende Tabelle enthält eine Erläuterung dieser Vorgänge.
- GET definiert einen Lesezugriff der Ressource ohne Nebeneffekte. Die Ressource wird niemals über eine GET-Anforderung geändert, z. B. hat die Anforderung keine Nebenwirkungen (idempotent).
- PUT erstellt eine neue Ressource. Es muss auch idempotent sein.
- DELETE entfernt die Ressourcen. Die Operationen sind idempotent. Sie können wiederholt werden, ohne zu unterschiedlichen Ergebnissen zu führen.
- POST aktualisiert eine vorhandene Ressource oder erstellt eine neue Ressource.
REST definiert 6 Architektureinschränkungen, aus denen jeder Webdienst hervorgeht - eine true-RESTful-API.
- Einheitliche Schnittstelle
- Kundenserver
- Staatenlos
- Zwischenspeicherbar
- Schichtsystem
- Code auf Anfrage (optional)
Reden ist mehr als nur Austauschen von Informationen. Ein Protokoll ist eigentlich so konzipiert, dass kein Reden stattfinden muss. Jede Partei weiß, was ihre spezielle Aufgabe ist, weil sie im Protokoll angegeben ist. Protokolle ermöglichen den reinen Informationsaustausch auf Kosten eventueller Änderungen. Beim Reden dagegen kann eine Partei fragen, welche weiteren Maßnahmen von der anderen Partei ergriffen werden können. Sie können sogar dieselbe Frage zweimal stellen und erhalten zwei unterschiedliche Antworten, da sich der Zustand der anderen Partei in der Zwischenzeit geändert hat. Reden ist RESTful Architektur . Die These von Fielding spezifiziert die Architektur, der man folgen müsste, wenn man Maschinen talk, anstatt einfach communic, zulassen möchte.
REST steht für Representational state transfer.
Es basiert auf einem zustandslosen, Client-Server-Cachefähigen Kommunikationsprotokoll - und in praktisch allen Fällen wird das HTTP-Protokoll verwendet.
REST wird häufig in mobilen Anwendungen, Websites für soziale Netzwerke, Mashup-Tools und automatisierten Geschäftsprozessen verwendet. Der Stil REST betont, dass die Interaktionen zwischen Clients und Services durch eine begrenzte Anzahl von Operationen (Verben) verbessert werden. Flexibilität wird durch die Zuordnung von Ressourcen (Nomen) zu eigenen eindeutigen universellen Ressourcenindikatoren (URIs) ermöglicht.
Es gibt keinen Begriff wie "REST-Programmierung" per se. Es wird besser als REST-Paradigma oder besser als REST-Architektur bezeichnet. Es ist keine Programmiersprache. Es ist ein Paradigma.
Repräsentational State Transfer (REST) ist im Rechnen eine Baustil für die Webentwicklung.
Wenn wir uns darauf einigen, eine gemeinsame Sprache für grundlegende Operationen (die http-Verben) zu verwenden, kann die Infrastruktur so konfiguriert werden, dass sie verstanden und optimiert wird, z. B. indem Cache-Header verwendet werden, um überhaupt Caching zu implementieren Ebenen.
Bei einer ordnungsgemäß implementierten restful GET-Operation sollte es keine Rolle spielen, ob die Informationen aus der Datenbank Ihres Servers, dem Memcache Ihres Servers, einem CDN, dem Cache eines Proxys, dem Cache Ihres Browsers oder dem lokalen Speicher Ihres Browsers stammen. Die am schnellsten verfügbare, aktuellste Quelle kann verwendet werden.
Wenn Sie sagen, dass Rest nur eine syntaktische Änderung darstellt, von der Verwendung von GET-Anforderungen mit einem Aktionsparameter bis zur Verwendung der verfügbaren http-Verben, sieht es so aus, als hätte es keine Vorteile und ist rein kosmetisch. Es geht darum, eine Sprache zu verwenden, die von jedem Teil der Kette verstanden und optimiert werden kann. Wenn Ihre GET-Operation eine Aktion mit Nebenwirkungen hat, müssen Sie das gesamte HTTP-Caching überspringen, oder Sie erhalten inkonsistente Ergebnisse.
Dies wird überall weniger erwähnt, aber das Richardson Maturity Model ist eine der besten Methoden, um tatsächlich zu beurteilen, wie restful die API eines Menschen ist. Mehr dazu hier:
Was ist API-Test ?
API-Tests verwenden Programmierungen, um Aufrufe an die API zu senden und den Ertrag zu erhalten. Die Prüfung betrachtet das zu testende Segment als Black Box. Das Ziel des API-Tests besteht darin, die korrekte Ausführung und die fehlerhafte Behandlung des Teils zu überprüfen, der seiner Koordination in eine Anwendung vorangeht.
REST API
REST: Repräsentativer Zustandstransfer.
- Es handelt sich um eine Anordnung von Funktionen, bei denen die Tester Anfragen ausführen und Antworten erhalten. In REST werden API-Interaktionen über das HTTP-Protokoll vorgenommen.
- REST ermöglicht auch die Kommunikation zwischen Computern über ein Netzwerk.
- Für das Senden und Empfangen von Nachrichten müssen HTTP-Methoden verwendet werden. Im Gegensatz zu Web-Services ist keine strikte Nachrichtendefinition erforderlich.
- REST-Nachrichten akzeptieren das Formular häufig entweder in Form von XML oder in JavaScript Object Notation (JSON).
4 Häufig verwendete API-Methoden: -
- GET: - Bietet nur Lesezugriff auf eine Ressource.
- POST: - Ermöglicht das Erstellen oder Aktualisieren einer neuen Ressource.
- PUT: - Wird verwendet, um eine vorhandene Ressource zu aktualisieren oder zu ersetzen oder eine neue Ressource zu erstellen.
- DELETE: - Wird zum Entfernen einer Ressource verwendet.
Schritte zum manuellen Testen der API: -
Um die API manuell zu verwenden, können wir browserbasierte REST - API-Plugins verwenden.
- Installieren Sie das POSTMAN (Chrome)/REST (Firefox) Plugin
- Geben Sie die API-URL ein
- Wählen Sie die Methode REST
- Wählen Sie den Inhalt-Header aus
- Geben Sie Request JSON (POST) ein.
- Klicken Sie auf Senden
- Die Antwort wird ausgegeben
Ich würde sagen, dass ein wichtiger Baustein für das Verständnis von REST in den Endpunkten oder Zuordnungen wie /customers/{id}/balance liegt.
Sie können sich einen solchen Endpunkt als die Verbindungsleitung von der Website (Front-End) zu Ihrer Datenbank/Ihrem Server (Back-End) vorstellen. Mit ihnen kann das Front-End Back-End-Vorgänge ausführen, die in den entsprechenden Methoden einer beliebigen REST Zuordnung in Ihrer Anwendung definiert sind.
Diese Antworten, die Beispiele für verknüpfte Ressourcen geben, sind großartig, aber nur die Hälfte des Bildes.
Stellen Sie sich vor, Sie entwerfen eine Website. Du schreibst eine Geschichte,
Ich möchte in der Lage sein, eine Adresse nach Postleitzahl zu suchen, damit ich eine Lieferadresse auswählen kann
Dann erstellen Sie die Website, um den Benutzer auf diese Reise zu bringen, und versuchen Sie, die Seiten in einem Workflow miteinander zu verknüpfen.
Ein Website-Design, das sie zu einer Adresssuche brachte, dann jedoch die Adresse in die Zwischenablage kopierte und dann zum Versandadressenformular zurückkehrte, wäre nicht sehr nützlich.
Eine REST - API verwendet Muster, die wir im Web für eine Maschine-Maschine-Interaktion als selbstverständlich voraussetzen.
Die Suche nach einer Postleitzahl-Funktion sollte nicht base/addresses/{postcode} sein, und eine Sammlung wird zurückgegeben, auch wenn jede Adresse mit einer vollständigen Adresse und einigen Bearbeitungslinks verknüpft ist, da dies eine Sackgasse ist. Der API-Verbraucher muss erraten, wie die Adresse verwendet wird.
Stattdessen sollte das Motiv für das Feature in den Fluss integriert werden, in dem es verwendet wird, sodass die Reise am Anfang endet:
1 GET /orders/123/shipping
200 OK { Current shipping details + link to parent + link to address picker }
2 -> GET /orders/123/shipping/addresspicker
200 OK { Link and form for searching for a postcode }
3 -> GET /orders/123/shipping/addresspicker?postcode=tn11tl
200 OK { List of addresses each with link to pick it }
4 -> POST /orders/123/shipping/addresspicker?postcode=tn11tl&pickNo=3
200 OK { Current shipping details + link to parent + link to address picker }
Es ist eine Benutzerreise und am Ende können Sie die Auswirkungen des Flusses auf die Bestellung sehen.
Die HTTP-Anfrage/Antwort ist nicht unbedingt Teil von REST, aber ich glaube nicht, dass jemals jemand eine Nicht-HTTP-Anwendung REST gesehen hat.
Nun, diese URLs könnten aus einer beliebigen Menge von Zeichen bestehen, sie sind nur Bezeichner. Ich habe sie hübsch gemacht, weil sie für Menschen sinnvoll sind. Eine Maschine würde die rel verwenden, um herauszufinden, was sie tun, und nicht von einer lesbaren href abhängen.