Was genau ist RESTful-Programmierung?

Question

Was genau ist RESTful-Programmierung?

Answer 1

Diese Antwort ist für absolute Anfänger gedacht. Wir wollen die heute am häufigsten verwendete API-Architektur kennenlernen.

Restful-Programmierung oder Restful-API verstehen. Zunächst müssen Sie verstehen, was API ist. Auf einer sehr hohen Ebene steht API für Application Programming Interface (Anwendungsprogrammierschnittstelle) und ist im Grunde ein Stück Software, das von einem anderen Stück Software verwendet werden kann, damit Anwendungen miteinander kommunizieren können.

Die weltweit am häufigsten verwendete Art von API ist die Web-API, bei der eine Anwendung Daten an einen Client sendet, sobald eine Anfrage eingeht.

In der Tat werden APIs nicht nur zum Senden von Daten verwendet und haben nicht immer etwas mit Webentwicklung oder Javascript oder Python oder einer anderen Programmiersprache oder einem Framework zu tun.

Die Anwendung in der API kann tatsächlich viele verschiedene Dinge bedeuten, solange das Stück Software relativ eigenständig ist. Nehmen wir zum Beispiel das Dateisystem oder die HTTP-Module, so können wir sagen, dass es sich um kleine Softwareteile handelt, die wir verwenden können, wir können mit ihnen interagieren, indem wir ihre API verwenden. Wenn wir zum Beispiel die Funktion read file für ein Dateisystemmodul einer beliebigen Programmiersprache verwenden, benutzen wir eigentlich die file_system_reading API. Oder wenn wir DOM-Manipulationen im Browser vornehmen, verwenden wir nicht die JavaScript-Sprache selbst, sondern die DOM-API, die uns der Browser zur Verfügung stellt, damit wir darauf zugreifen können. Oder ein anderes Beispiel: Wir erstellen eine Klasse in einer beliebigen Programmiersprache wie Java und fügen ihr dann einige öffentliche Methoden oder Eigenschaften hinzu. Diese Methoden sind dann die API jedes Objekts, das aus dieser Klasse erstellt wird, weil wir anderen Teilen der Software die Möglichkeit geben, mit unserem ursprünglichen Teil der Software, in diesem Fall den Objekten, zu interagieren. S0, API hat eigentlich eine breitere Bedeutung als nur die Erstellung von Web-APIs.

Werfen wir nun einen Blick auf die REST-Architektur zur Erstellung von APIs.

REST was für Representational State Transfer steht, ist im Grunde eine Möglichkeit, Web-APIs auf logische Weise zu erstellen, so dass sie für uns selbst oder für andere leicht zu nutzen sind.

Um Restful APIs nach der REST-Architektur zu erstellen, müssen wir nur einige Grundsätze beachten. 1. Wir müssen unsere API in logische Ressourcen aufteilen. 2. Diese Ressourcen sollten dann unter Verwendung ressourcenbasierter URLs zugänglich gemacht werden. 3. Zur Durchführung verschiedener Aktionen mit Daten wie Lesen, Erstellen oder Löschen von Daten sollte die API die richtigen HTTP-Methoden und nicht die URL verwenden. 4. Die Daten, die wir an den Client zurücksenden oder vom Client erhalten, sollten in der Regel das JSON-Datenformat verwenden, auf das ein Formatierungsstandard angewendet wird. 5. Schließlich ist ein weiterer wichtiger Grundsatz von EST-APIs, dass sie zustandslos sein müssen.

Trennen Sie APIs in logische Ressourcen: Die wichtigste Abstraktion von Informationen in REST ist eine Ressource, und daher sollten alle Daten, die wir in der API gemeinsam nutzen wollen, in logische Ressourcen unterteilt werden. Was ist eigentlich eine Ressource? Nun, im Kontext von REST ist es ein Objekt oder eine Darstellung von etwas, dem einige Daten zugeordnet sind. Zum Beispiel sind Anwendungen wie Tour-Guide-Touren oder Benutzer, Orte oder Rezensionen ein Beispiel für logische Ressourcen. Grundsätzlich kann also jede Information, die benannt werden kann, eine Ressource sein. Allerdings muss sie nur benannt werden, nicht als Verb.

Struktur freilegen: Nun müssen wir die Daten mit Hilfe von strukturierten URLs, an die der Client eine Anfrage senden kann, zur Verfügung stellen. Zum Beispiel so etwas wie diese ganze Adresse wird als URL bezeichnet. und dies / addNewTour wird als API-Endpunkt bezeichnet.

Unsere API wird viele verschiedene Endpunkte haben, wie z.B.

https://www.tourguide.com/addNewTour
https://www.tourguide.com/getTour
https://www.tourguide.com/updateTour
https://www.tourguide.com/deleteTour
https://www.tourguide.com/getRoursByUser
https://www.tourguide.com/deleteToursByUser

Jede dieser APIs sendet unterschiedliche Daten an den Client zurück und führt auch unterschiedliche Aktionen durch. Jetzt gibt es etwas sehr Falsches mit diesen Endpunkten hier, weil sie wirklich nicht die dritte Regel befolgen, die besagt, dass wir nur die HTTP-Methoden verwenden sollten, um Aktionen mit Daten durchzuführen. Endpunkte sollten also nur unsere Ressourcen enthalten und nicht die Aktionen, die wir mit ihnen durchführen, weil sie schnell zu einem Alptraum in der Wartung werden.

Wie sollten wir diese HTTP-Methoden in der Praxis verwenden? Nun, lassen Sie uns sehen, wie diese Endpunkte tatsächlich aussehen sollten, beginnend mit /getTour. Dieser getTour-Endpunkt dient dazu, Daten über eine Tour zu erhalten. Wir sollten den Endpunkt also einfach /tours nennen und die Daten immer dann senden, wenn eine get-Anfrage an diesen Endpunkt gestellt wird. Mit anderen Worten, wenn ein Client eine GET-HTTP-Methode für den Zugriff auf den Endpunkt verwendet,

(wir haben nur Ressourcen im Endpunkt oder in der URL und keine Verben, weil das Verb jetzt in der HTTP-Methode ist, richtig? Die übliche Praxis, den Ressourcennamen immer im Plural zu verwenden, weshalb ich /tours noch /tour geschrieben habe). Die Konvention ist, dass beim Aufruf des Endpunkts /tours alle Touren in der Datenbank zurückgegeben werden, aber wenn wir nur die Tour mit einer ID, sagen wir sieben, wollen, fügen wir die sieben nach einem weiteren Schrägstrich (/tours/7) oder in einer Suchabfrage (/tours?id=7) hinzu, und natürlich könnte es auch der Name einer Tour statt der ID sein.

HTTP-Methoden: Wichtig ist hier, dass der Name des Endpunkts für alle derselbe Name ist.

GET: (for requesting data from the server.)

https://www.tourguide.com/tours/7
POST: (for sending data to the server.)
https://www.tourguide.com/tours
PUT/PATCH: (for updating requests for data to the server.) https://www.tourguide.com/tours/7
DELETE: (for deleting request for data to the server.)
https://www.tourguide.com/tours/7

Der Unterschied zwischen PUT und PATCH-> Bei der Verwendung von PUT soll der Client das gesamte aktualisierte Objekt senden, während er bei PATCH nur den Teil des Objekts senden soll, der geändert wurde.

Durch die Verwendung von HTTP-Methoden können Benutzer die vier grundlegenden CRUD-Operationen durchführen. CRUD steht für Create (Erstellen), Read (Lesen), Update (Aktualisieren) und Delete (Löschen).

Jetzt könnte eine Situation wie ein Blasebalg entstehen:

So kann /getToursByUser einfach in /users/tours übersetzt werden, für Benutzer Nummer 3 wird der Endpunkt wie /users/3/tours lauten.

Wenn wir eine bestimmte Tour eines bestimmten Benutzers löschen wollen, dann sollte die URL wie /users/3/tours/7 lauten, hier Benutzer-ID: 3 und Tour-ID: 7.

Es gibt also wirklich eine Menge Möglichkeiten, Ressourcen auf diese Weise zu kombinieren.

Daten als JSON senden: Was nun die Daten betrifft, die der Client tatsächlich erhält oder die der Server vom Client erhält, so verwenden wir normalerweise das JSON-Datenformat. Ein typisches JSON könnte wie unten aussehen: Vor dem Senden von JSON-Daten führen wir in der Regel eine einfache Antwortformatierung durch. Dafür gibt es mehrere Standards, aber einer der sehr einfachen heißt Jsend. Wir erstellen einfach ein neues Objekt und fügen ihm eine Statusmeldung hinzu, um dem Client mitzuteilen, ob die Anfrage erfolgreich, fehlgeschlagen oder fehlerhaft war. Und dann fügen wir unsere ursprünglichen Daten in ein neues Objekt namens Data ein.

Das Umhüllen der Daten in ein zusätzliches Objekt, wie wir es hier getan haben, wird als Enveloping bezeichnet und ist eine gängige Praxis, um einige Sicherheitsprobleme und andere Probleme zu entschärfen.

Restful API sollte immer zustandslos sein: Schließlich sollte eine RESTful-API immer zustandslos sein, was bedeutet, dass bei einer zustandslosen RESTful-API der gesamte Zustand auf der Client-Seite und nicht auf dem Server behandelt wird. Der Zustand bezieht sich einfach auf Daten in der Anwendung, die sich im Laufe der Zeit ändern können. Zum Beispiel, ob ein bestimmter Benutzer eingeloggt ist oder auf einer Seite mit einer Liste mit mehreren Seiten, was die aktuelle Seite ist? Die Tatsache, dass der Status auf dem Client gehandhabt werden sollte, bedeutet, dass jede Anfrage alle Informationen enthalten muss, die für die Verarbeitung einer bestimmten Anfrage auf dem Server erforderlich sind. Der Server sollte sich also niemals an die vorherige Anfrage erinnern müssen, um die aktuelle Anfrage bearbeiten zu können.

Nehmen wir an, wir befinden uns derzeit auf Seite fünf und wollen zu Seite sechs weitergehen. Wir könnten also einen einfachen Endpunkt mit dem Namen /tours/nextPage haben und eine Anfrage an den Server senden, aber der Server müsste dann herausfinden, was die aktuelle Seite ist, und auf der Grundlage dessen wird der Server die nächste Seite an den Client senden. Mit anderen Worten, der Server müsste sich an die vorherige Anfrage erinnern. Genau das wollen wir bei RESTful-APIs vermeiden.

Anstelle dieses Falles sollten wir einen /tours/page-Endpunkt erstellen erstellen und dort die Zahl sechs einfügen, um die Seite Nummer sechs /tours/page/6 anzufordern. Der Server muss sich also nichts merken, sondern nur die Daten für die Seite Nummer sechs zurücksenden, wie wir sie angefordert haben.

Statelessness und Statefulness, also das Gegenteil, sind sehr wichtige Konzepte in der Informatik und bei Anwendungen im Allgemeinen

Answer 2

Dies ist eine erstaunlich lange "Diskussion" und doch ziemlich verwirrend, um es vorsichtig auszudrücken.

IMO:

1) Es gibt kein erholsames Programmieren, ohne einen großen Joint und viel Bier :)

2) Representational State Transfer (REST) ist ein Architekturstil, der in die Dissertation von Roy Fielding . Sie unterliegt einer Reihe von Einschränkungen. Wenn Ihr Dienst/Client diese einhält, ist er RESTful. Das ist es.

Sie können die Zwänge (deutlich) zusammenfassen zu :

• zustandslose Kommunikation
• Einhaltung der HTTP-Spezifikationen (wenn HTTP verwendet wird)
• die übermittelten Inhaltsformate klar kommuniziert
• Verwendung von Hypermedia als Motor für den Anwendungsstatus

Es gibt eine weitere sehr guter Beitrag was die Dinge gut erklärt.

In vielen Antworten wurden gültige Informationen kopiert und eingefügt, was zu Verwirrung führte. Die Leute reden hier über Ebenen, über RESTFul URIs (so etwas gibt es nicht!), wenden HTTP-Methoden GET,POST,PUT an ... REST ist nicht das oder nicht nur das.

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/versenden, es ist der Inhalt, der zählt.

Am Ende Jeder RESTful-Client sollte in der Lage sein, jeden RESTful-Dienst zu nutzen, solange das Inhaltsformat bekannt ist.

Answer 3

REST ist ein Architekturstil, der auf Web-Standards und dem HTTP-Protokoll (eingeführt im Jahr 2000) basiert.

In einer REST-basierten Architektur ist alles eine Ressource (Benutzer, Aufträge, Kommentare). Der Zugriff auf eine Ressource erfolgt über eine gemeinsame Schnittstelle auf der Grundlage der HTTP-Standardmethoden (GET, PUT, PATCH, DELETE usw.).

In einer REST-basierten Architektur haben Sie einen REST-Server, der eine Zugriff auf die Ressourcen bietet. Ein REST-Client kann auf die REST-Ressourcen zugreifen und diese Ressourcen zugreifen und sie verändern.

Jede Ressource sollte die üblichen HTTP-Vorgänge unterstützen. Ressourcen werden durch globale IDs identifiziert (die in der Regel URIs sind).

REST erlaubt, dass Ressourcen unterschiedliche Darstellungen haben, z.B. Text, XML, JSON usw. Der REST-Client kann über das HTTP-Protokoll nach einer bestimmten Darstellung fragen (Content Negotiation).

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 Operationen.

• GET definiert einen lesenden Zugriff auf die Ressource ohne Nebeneffekte. Die Ressource wird durch eine GET-Anfrage nie verändert, d.h. die Anfrage hat keine Nebenwirkungen (idempotent).
• PUT erstellt eine neue Ressource. Sie muss außerdem idempotent sein.
• DELETE löscht die Ressourcen. Die Vorgänge sind idempotent. Sie können wiederholt werden, ohne zu unterschiedlichen Ergebnissen zu führen.
• POST aktualisiert eine vorhandene Ressource oder erstellt eine neue Ressource.

Answer 4

REST === Die HTTP-Analogie ist erst dann richtig, wenn man nicht betont, dass es ein "MUSS" ist HATEOAS gefahren.

Roy selbst hat es geklärt aquí .

Eine REST-API sollte ohne Vorkenntnisse über den anfänglichen URI (Lesezeichen) und eine Reihe von standardisierten Medientypen eingegeben werden, die für die vorgesehene Zielgruppe geeignet sind (d. h. von denen erwartet wird, dass sie von jedem Client, der die API verwenden könnte, verstanden werden). Von diesem Zeitpunkt an müssen alle Zustandsübergänge der Anwendung durch die Auswahl des Clients aus den vom Server bereitgestellten Auswahlmöglichkeiten gesteuert werden, die in den empfangenen Darstellungen enthalten sind oder durch die Manipulation dieser Darstellungen durch den Benutzer impliziert werden. Die Übergänge können durch das Wissen des Clients über Medientypen und Ressourcenkommunikationsmechanismen bestimmt (oder begrenzt) werden, die beide on-the-fly verbessert werden können (z. B. Code-on-demand).

[Das Scheitern impliziert, dass die Interaktion nicht durch Hypertext, sondern durch Out-of-Band-Informationen gesteuert wird.]

Answer 5

REST steht für Repräsentative Zustandsübertragung .

Es basiert auf einem zustandslosen, Client-Server- und 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 REST-Stil betont, dass die Interaktion zwischen Clients und Diensten durch eine begrenzte Anzahl von Operationen (Verben) verbessert wird. Die Flexibilität wird dadurch gewährleistet, dass den Ressourcen (Substantiven) eigene, eindeutige universelle Ressourcenindikatoren (URIs) zugewiesen werden.

Einführung über Rest