Dienste kommunizieren und REST-API-Konzept
- 24-07-2022
- Toanngo92
- 0 Comments
Mục lục
Einführung in die REST-API
REST ist eine zustandslose Architektur , REST wird verwendet, um eine Anwendung zu erstellen, die über das Netzwerk kommuniziert, erfunden und eingeführt im Jahr 2000 und stellt ein Protokoll für die maschinenseitige Kommunikation zwischen Client und Server bereit. In den meisten Fällen verwendet diese Architektur ein Protokoll namens Hypertext Transfer Protocol (HTTP), um zwischen Geräten zu kommunizieren.
Vor der Einführung der REST-Architektur verwendeten Programmierer komplexe Kommunikationsarchitekturen mit grundlegenden Konzepten wie:
- Simple Object Access Protocol (grob übersetzt als grundlegendes Objektzugriffsprotokoll) wird als SOAP abgekürzt. Sehen Sie mehr hier
- Remote Procedure Call (Remote Procedure Call) wird mit RPC abgekürzt. Sehen Sie mehr hier
- Common Object Request Broker Architecture wird als COBRA abgekürzt. Sehen Sie mehr hier
Wir verstehen vorübergehend, dass REST eine leichtgewichtige Architektur ist, die für Webdienste verwendet wird. Mit vielen verschiedenen Perspektiven hat das WWW (World Wide Web), das auf dem HTTP-Protokoll basiert, eine REST-basierte Architektur hervorgebracht. REST ist wirklich optimal für das Internet, da Anwendungen, die das HTTP-Protokoll verwenden, immer noch beliebt und leistungsfähig sind. (Falls Sie das nicht verstehen, stellen Sie sich vor, wenn Sie den Domänennamen web888.vn in den Browser eingeben, fügt der Browser automatisch http:// oder https:// vor der Zeichenfolge des Domänennamens hinzu, außerdem fügen einige Websites http hinzu :/ /www.tenmien.com, d.h. der Browser setzt beim Zugriff auf die Webanwendung standardmäßig das http-Protokoll)
REST antwortet auf eine clientseitige Anforderung mit vier Operationen, die konzeptionell als Create, Read, Update, Delete (CRUD) bezeichnet werden. Eine RESTful-Anwendung sendet HTTP-Anforderungen (Requests), die zum Lesen, Hinzufügen, Aktualisieren oder Löschen von Daten verwendet werden. Kurz gesagt, REST bietet eine leicht verständliche Architektur, mit der wir die Daten nach Belieben manipulieren und anpassen können, und wird als Standardbibliotheksfunktion in Sprachen wie C#, Java, Perl … bereitgestellt.
Obwohl diese REST-Architektur ziemlich umfassend ist, mit anderen Worten, sie bietet alle Funktionen, kann sie als alles tun bezeichnet werden, aber diese Dinge können durch sogenannte Webdienste (Webdienste), REST, die vom W3C nicht empfohlen werden, und nicht durch den Standardmechanismus ausgeführt werden
REST-Prinzipien
Der REST-Stil besteht darin, eine Reihe von Einschränkungen zu definieren, die zum Erstellen einer häufig verwendeten Architektur verwendet werden. Diese Einschränkungen sind die Prinzipien oder Merkmale, die REST-Architekturen von anderen Architekturen unterscheiden
- Client-Server-Kommunikation : Grundsätzlich in 2 Schichten unterteilt: Client und Server sind 2 separate Komponenten, die RESTful-Anwendung stellt sicher, dass sie funktionieren, und hilft dem Client (Client), mit dem Server (Server) zu kommunizieren.
- Zustandslosigkeit : Client-Statusinformationen werden nicht auf dem Server gespeichert. Mit anderen Worten, jede clientseitige Anfrage enthält alle erforderlichen Informationen, der Server empfängt die Informationen und führt die Aufgabe aus. Es ermöglicht dem Server, clientseitige Aufgaben und den Status jeder Kommunikationssitzung zu verstehen, und die an den Client zurückgegebenen Daten enthalten auch Sitzungsinformationen für jede Anforderung (Abfrage). Stelessness hilft dabei, einen straffen Mechanismus zur Kommunikation zwischen dem Server und dem Client bereitzustellen, um den Zweck der Aufgabe zu erreichen
- Cache -Fähigkeit: Der Client kann die zurückgegebenen Daten vorübergehend zwischenspeichern und selbst beschreiben, ob die Daten zwischengespeichert werden können oder nicht. Wenn dies der Fall ist, werden die Daten für die nächste Antwort wiederverwendet, um die Antwortzeit zu verlängern
- Einheitliche Schnittstelle : Eine Standardschnittstelle, die die Interaktion mit allen Komponenten erleichtert, was die Interaktion mit verschiedenen Diensten vereinfacht. Es hilft auch sicherzustellen, dass sich Entwicklungsänderungen nicht auf andere Komponenten der Anwendung auswirken, auf der anderen Seite, dass der Standard nicht geändert werden kann.
- Schichtensystem : Ein Vermittler, wie ein Proxy, der die Kommunikation zwischen dem Client und dem Server für einen bestimmten Zweck wie Sicherheit, Lastausgleich oder Caching unterbrechen kann. Und der Client kann nicht erkennen, ob er mit dem Server oder einem Vermittler kommuniziert
- Code on Demand : Dies ist eine willkürliche Einschränkung, bei der der Server die Funktionalität des Clients vorübergehend erweitert, indem er ihm erlaubt, Programme herunterzuladen, die dann auf dem Client ausgeführt werden. Beispielsweise kann ein Client Javascript-Code ausführen, um mit einem anderen darauf ausgeführten Dienst zu interagieren
Vergleichen Sie REST und SOAP
Viele Programmierer (mich eingeschlossen) fragen, warum REST besser geeignet ist als SOAP.Für Neulinge ist es wirklich schwierig, weil wir heutzutage wirklich selten Zugriff auf SOAP haben. Erstens ist es praktisch unmöglich, REST und SOAP direkt zu vergleichen, da SOAP ein Protokoll und REST ein Architekturstil ist.
Die Punkte, die uns bei der Bewertung zwischen SOAP und REST helfen, sind jedoch die folgenden:
Unterschied | SEIFE | SICH AUSRUHEN |
Kohärenz zwischen Client- und Serverimplementierungen | Gebunden an den Server, beispielsweise eine benutzerdefinierte Computeranwendung, besteht zwischen dem Client und dem Server ein enger Vertrag, der als Bindung verstanden werden kann. Wenn sich einer von ihnen ändert, wird alles im Kommunikationsprozess unterbrochen | Ein lose gekoppelter Mechanismus wie ein Browser, ein REST-Client ist eine Client-Anwendung, die gemeinsame standardisierte Methoden und Protokolle teilt, an die sich die Anwendung anpasst. Es sind keine zusätzlichen Methoden definiert, um Protokollstandards zu verletzen. Änderungen werden einfacher gehandhabt |
Orientierung | Thema | Ressourcen |
Größe | Schwer | Licht |
Status | Staatsbürgerlich | Staatenlos |
Standard | Klare Datenstandards | Datenstandards sind nicht klar |
Geschwindigkeit | Langsamer und verbraucht mehr Ressourcen und Bandbreite pro Kommunikation | Schneller, da weniger Bandbreite und Ressourcen verbraucht werden |
Kommunikationsstandards | eXtensible Markup Language (XML) | Verwenden Sie die Nachrichtensteuerung zum Interpretieren mit vielen modernen Datenstrukturen wie XML, Klartext, JSON |
Implementierung | Komplizierter (schwieriger) | Einfacher |
Klient | Vor der Interaktion ist ein vollständiges Verständnis der verwendeten Datenarchitekturen erforderlich | Keine API-Kenntnisse erforderlich, außer für den Einstiegspunkt und den Rückgabedatentyp |
Ressourcen in RESTful-Webdiensten
Ein RESTful-Webdienst ist ein Kommunikationsgeschäft (Dienst) in der Webtechnologie, das sich aus der REST-API-Architektur entwickelt hat. Es verfügt über vordefinierte URIs ( Uniform Resource Identifier ), die auf die geschäftlichen HTTP-Methoden hinweisen.
In der RESTful-API sind alle Probleme rund um das Konzept (Ressource), das als Ressource übersetzt werden kann, wie folgt zu verstehen: Jedes Mal, wenn wir direkte API-Methoden implementieren, arbeiten wir mit Ressourcen, es kann sich um ein Dokument, ein Bild, eine Datei oder ein Web handeln Seite …. Eine Ressource hat einen Typ (kann als Daten visualisiert werden), der Daten enthält, und sie hat eine Sammlung von Methoden, um sie zu manipulieren, und hat möglicherweise Beziehungen zu anderen Ressourcen.
Ressource in REST entspricht dem Objektkonzept in objektorientierten Programmiersprachen, wie z. B. beim Problem der Schülerverwaltung, Hinzufügen, Bearbeiten und Löschen von Klassikern in der Programmiersprache C, wobei jede Variable die Datenstruktur der Schüler darstellt (einschließlich Name, Alter, Klasse ), in modernen Programmiersprachen mit neuer Stilsyntax ist es ein Objekt. Und um sie hinzuzufügen und zu entfernen, bietet REST einige grundlegende Methoden mit dem CRUD-Konzept, an die wir uns wenden können. In der Praxis können wir jedoch mehr Methoden verwenden, aber normalerweise sind die folgenden 4 Methoden gerade ausreichend und ausreichend, um sie zu verwenden:
- POST (Create): initialisiert eine neue Ressource oder kann in einigen Situationen auch verwendet werden, um eine vorhandene Ressource zu aktualisieren
- GET:(Read) Ruft eine schreibgeschützte Ressource ab, die normalerweise zum Abrufen eines Objekts oder einer Liste von Objekten verwendet wird.
- PUT:(Update) aktualisiert verfügbare Ressourcen
- DELETE: (Löschen) Ressource löschen
Ressourcen (Ressource) können vollständig in einer Liste gruppiert werden, jede Liste ist auch eine Ressource (Ressource), kann als solche verstanden werden, diese Liste darf nicht sortiert sein und hat eine einheitliche, einheitliche Datenstruktur und wir können diese Daten zur weiteren Verarbeitung verwenden in Programmiersprachen wie Parsing in Arrays, Normalisierung auf primitive Datentypen, Anzeige von Benutzeroberflächen .. ..
Ein REST-Server ermöglicht den Zugriff auf Ressourcen und der Client stellt sie dar. Jede Ressource hat eine eindeutige Kennung, die auf dem Standard-URI basiert (normalerweise ein Parameter, Slug – ein Element des Übertragungspfads). Zum Beispiel ein API-Endpunkt, wie gezeigt, um einen Endpunkt darzustellen, der mit einer Ressource arbeitet, um Aufgaben zu verwalten (kann als Objekt verstanden werden):
Für die Ressourcendarstellung unterstützt REST eine Vielzahl von Datenstrukturen von strikt (XML) bis modern (JSON) oder einfach nur Text (PLAINTEXT). Derzeit und auf absehbare Zeit ist JSON immer noch am beliebtesten, wenn es um die Nutzung von Webdiensten geht.
HTTP-Nachrichten
Wir können HTTP-Nachrichten als Antwortnachrichten bei der Kommunikation mit HTTP verstehen, der RESTful-Webdienst verlässt sich auf HTTP, um die Kommunikation zu initiieren oder Nachrichten auszugeben, wenn der Client mit dem Server kommuniziert. Während der Verarbeitung der Nachricht sendet der Client eine HTTP-Anforderung an den Server, der Server sendet an den Client ein Paket namens HTTP-Antwort zurück, die Anforderungs- und Antwortnachricht enthält den Nachrichteninhalt (Nachricht) mit Informationen über die Daten, die als Metadaten bezeichnet werden. Die Struktur ist wie folgt:
HTTP-Anforderungsstruktur
- Verb : steht für HTTP-Methoden wie GET, DELETE, PUT, POST
- URI : kann grob als Zielpfad verstanden werden, der die gewünschte Ressource identifiziert, die auf dem Server arbeiten soll
- HTTP-Version : stellt die Version von HTTP dar (z. B. v1.1)
- Request Header : enthält die Metadaten der Datei mit standardmäßigen Schlüssel-Wert-Paaren. Beispielsweise fügen Metadaten Browserinformationen, Cache-Konfiguration und Format für den Nachrichtentext der Anfrage hinzu.
- Anforderungstext : enthält die Nachrichtendaten im entsprechenden Format
HTTP-Antwortstruktur
- HTTP-Version : stellt die Version von HTTP dar (z. B. v1.1)
- Antwortcode : 3 alphanumerische Zeichen, die den Status der angeforderten Ressource angeben. Zum Beispiel ist 200 in Ordnung, 404 ist Ressource nicht gefunden
- Response Header : enthält Metadaten mit Antwortnachricht mit Schlüssel-Wert-Paaren. Metadaten-Tags können beispielsweise Inhaltslänge, Antwortdatum, Servertyp und Inhaltstyp enthalten
- Antworttext : enthält die Dateidaten im entsprechenden Format
Beispielbild des Anforderungsheaders,
Antwortcode | Benachrichtigen | Beschreiben |
200 | OK | Erfolgreich |
201 | Erstellt | Zeigt an, dass die gewünschte Ressource erfolgreich erstellt oder über die PUT- oder POST-Methode aktualisiert wurde, und gibt über den Location-Header eine Verbindung zu ihr zurück. |
204 | Kein Inhalt | Erscheint, wenn der Antworttext weiß ist. Dieser Code wird beispielsweise angezeigt, wenn die DELETE-Anforderung erfolgreich ausgeführt wird |
304 | Nicht modifiziert | Wird zum Reduzieren der Bandbreitennutzung verwendet, wenn bedingte GET-Anforderungen vorhanden sind, der Antworttext leer ist und Header Metadaten wie Ort und Datum enthalten |
400 | Ungültige Anforderung | Gibt an, dass die clientseitige Eingabe ungültige Daten in der Anfrage enthält. Es kann beispielsweise fehlende Daten oder ungeeignete Parameter aufweisen |
401 | Unbefugt | Zeigt an, dass der Client nicht zugriffsberechtigt ist (nicht authentifiziert) |
403 | Verboten | Gibt an, dass auf den Client geklickt wurde, um die Methode auszuführen, z. B. die Codes, die angezeigt werden, wenn der Client keine Administratorrechte hat, aber eine DELETE-Datenanforderung für die Serverressource ausführen möchte. |
404 | Nicht gefunden | Zeigt an, dass die Methode nicht gefunden wurde |
409 | Konflikt | Gibt an, dass beim Ausführen der angeforderten Methode ein Konflikt aufgetreten ist. Dieser Code wird beispielsweise angezeigt, wenn der Client versucht, eine Ressource mit hinzuzufügen, die Ressource jedoch bereits vorhanden ist. |
500 | interner Serverfehler | Gibt an, dass der Server während der Methodenausführung eine Ausnahme abgefangen hat |
Für den Zugriff verwendete Software
Klient
Die Postman-Software kann beim Zugriff auf die REST-API als Client verwendet werden
Server
Wenn Sie Frameworks für die Codierung des Servers verwenden, wird es sicherlich einen Mechanismus geben, um eine API für den Server gemäß der Framework-Struktur zu erstellen. Wenn Sie dies nicht gelernt haben, können Sie sich an einige der Unternehmen wenden, die beliebte APIs zum Üben von Clients bereitstellen Kommunikation, zum Beispiel:
- Airtable : ein Zeilen- und Spalten-Datenbankspeichersystem mit ähnlichen Funktionen wie Excel, aber weiter entwickelt, das APIs bereitstellt, um mehr zu kommunizieren, zu bearbeiten und zu löschen
- Mapbox API: Free Map bietet eine API, um Karten online zeichnen zu können
- Openweather : Bietet eine API zum Abrufen des Wetters
- …
Der obige Artikel enthält grundlegende Konzepte für die Verwendung der REST-API zur Interaktion zwischen Client und Server, ich hoffe, dass Sie nach dem Lesen das Konzept der Architektur sowie die Verwendung der REST-API besser verstehen werden.