REST vs RESTful vs "normaler" Webservice

21

Ich habe einige Definitionen und Diskussionen zu REST und / oder RESTful-Anwendungen gelesen, verstehe aber immer noch nicht die wahre Bedeutung.

Normalerweise arbeite ich mit Apps, die entweder Daten über GET abrufen oder Daten über POST an einen Webdienst senden (normalerweise ein PHP-Skript), der dann entweder Daten aus der Datenbank abruft oder in die Datenbank schreibt.

Ist das eine RESTful-App? Wenn nicht, was wäre eine RESTful-App? Was ist der Unterschied zwischen dem RESTful-Konzept und dem Konzept, mit dem ich bisher gearbeitet habe? Bitte erläutern Sie anhand eines Beispiels.

Außerdem spricht jemand über REST und jemand über RESTful-Apps. Ich fand heraus, dass sich der Begriff REST auf das theoretische Konzept bezieht, während RESTful verwendet wird, wenn wir über die spezifische App sprechen. Ist das richtig oder gibt es echte Unterschiede zwischen REST- und RESTful-Apps?

— deviDave
quelle

1

Wenn Sie alle Servlets so erstellen können, dass sie Informationen NUR aus GET- oder POST-Parametern beziehen (absolut nichts, was vor dem Aufruf lokal gespeichert wurde), wenden Sie REST ordnungsgemäß an. Mit anderen Worten, der Server spielt in MVC die Rolle des Modells, da er nicht die Kontrolle hat, sondern lediglich das verwendet, was für die Ausführung einer Aufgabe angegeben wurde. Hoffe das erklärt es ein bisschen besser.

— Neil

@Neil Ich bin auf der anderen Seite - mobile App. Es ist ein Client, der den Webdienst nutzt und über POST und GET mit ihm kommuniziert. Alle Webservices wurden von jemand anderem erstellt und ich habe sie nur verwendet. Aber die Terminologie hat mich verwirrt. Wenn ich also einen HTTP-Kanal und HttpGet / HttpPost-Objekte verwende, habe ich es mit einer RESTful-App zu tun, oder?

— DeviDave

Nicht unbedingt. Es gibt keine Möglichkeit herauszufinden, ob es sich um eine RESTful-App handelt, wenn Sie nicht wissen, wie der Server funktioniert, da er möglicherweise gegen einige Einschränkungen verstößt. Das heißt, es ist wahrscheinlich RESTful, wenn es konsistente Ergebnisse liefert.

— Neil

@Neil Oh, ich verstehe jetzt. RESTful wird auf dem Server ausgeführt. Und wenn ich ein Post-Objekt mit einer Anfrage sende (nicht jeder Parameter einzeln), dann ist es wahrscheinlich ein REST-Ansatz. Für einen Client (mobile App) ist es egal, ob es sich um REST handelt oder nicht, da die Codierung identisch ist. Habe ich es richtig verstanden?

— DeviDave

2

RESTful ist sowohl Server als auch Client, aber wenn Sie nur den Client sehen können, können Sie nur wissen, ob der Client den Einschränkungen folgt. Das ist alles was ich meinte. Was ich mit REST meine, ist, wenn Sie sich anmelden müssen, geben Sie Benutzername und Passwort ein. Der Server überprüft die Anmeldung, speichert den Benutzer-Hash-Schlüssel in der Datenbank und gibt ihn zurück. Wenn Sie jetzt eine Operation ausführen müssen, für die eine Anmeldung erforderlich ist, übergeben Sie immer den Benutzer-Hash-Schlüssel. Der Server "vergisst", dass er Sie angemeldet hat, verwendet jedoch den Benutzer-Hash, um Ihren Anmeldestatus zu überprüfen. Wenn es nicht RESTful wäre, würde sich der Server daran erinnern, dass Sie angemeldet sind. Verstehen Sie den Unterschied?

— Neil

13

Die Hauptmerkmale einer RESTful-Anwendung sind: Die gesamte Kommunikation erfolgt über http GET, POST, PUT, DELETE, und alle Elemente werden über eine Standard-URL des Formulars adressiert, http://your.site.com/salesapp/salesperson/0000001/detailsdh nur eine reine URL ohne Parameter usw. Die URL identifiziert das Objekt, das GET , POST, PUT, DELETE gibt an, was Sie damit machen möchten.

Der Hauptgrund dafür ist, dass Sie automatisch einen zustandslosen Dienst haben, der lastausgeglichen, ausgefallen usw. usw. sein kann.

Die bloße Einfachheit des Schemas sorgt für eine sehr saubere Benutzeroberfläche, die den Client vollständig von einer bestimmten Back-End-Implementierung entkoppelt.

— James Anderson
quelle

Oh, bis jetzt habe ich weder PUT noch DELETE verwendet (mobile Apps machen normalerweise nur GET und POST), aber das sieht tatsächlich so aus, wie ich es gemacht habe und gerade mache. Es ist nur so, dass die Kunden keine REST *

— -Begriffe verwendeten

2

James, könnten Sie erklären, warum Abfrageparameter vermieden werden sollen? Wie kann ich zum Beispiel ausdrücken, dass die Ressourcen auf bestimmte Weise gefiltert werden sollen, ohne eine falsche Hierarchie einzuführen?

— Gary Rowe

3

@GaryRowe: Die URL (ohne Parameter) gibt die Ressource an, die Sie bearbeiten möchten. Sie können weiterhin Parameter verwenden, diese werden jedoch nicht zur Identifizierung der Ressource verwendet. Beispiel Ein GET in einem Verzeichnis (eine URL, die mit einem / endet) sollte eine Liste der Ressourcen im Verzeichnis zurückgeben. Ein Parameter in der URL kann verwendet werden, um eine Filter- oder Sortierreihenfolge oder ähnliches anzugeben.

— Martin York

1

Danke, Loki. James möchte seine Antwort möglicherweise dahingehend ändern, dass dies berücksichtigt wird, da es den Anschein hat, dass er die Verwendung von Abfrageparametern unter keinen Umständen zulässt, die irreführend sein könnten. Tatsächlich gibt es eine interessante Beobachtung, dass die Liste der Ressourcen in einem Verzeichnis selbst eine Ressource ist, die dieses Konzept ausdrückt.

— Gary Rowe

Für REST muss die App weder URL-basiert sein, noch müssen Verben wie GET, POST, DELETE usw. vorhanden sein. Für eine WebApp ist URL jedoch die einzige Option und die oben genannten Verben.

— Nawaz

6

REST steht für Representational State Transfer. Wenn Ihre Software den REST-Einschränkungen entspricht, wird sie als REST- konform eingestuft .

Nun, da ich schamlos aus Wikipedia herausgerissen habe, was bedeutet das wirklich? Es bedeutet effektiv, die eingebauten HTTP-Befehle wie GET, POST, PUT, DELETE und einige andere seltenere zu verwenden, um zwischen einem Client und einem Server hin und her zu kommunizieren.

Was Sie tun, klingt wie eine RESTFul-App. Es gibt jedoch einen großen Unterschied zwischen gut gestalteten und überladenen RESTFul-Webdiensten. Beispielsweise könnte der PHP-Code am anderen Ende des GET eine Statusänderung ausführen, die als falsch angesehen wird, da ein GET als schreibgeschützte Operation angesehen wird. Es gibt subtile Unterschiede zwischen der Verwendung von POST (neu) und PUT (ersetzen).

Der Wikipedia-Artikel dazu ist wirklich gut, also höre ich hier auf.

— Martijn Verburg
quelle

Bisher habe ich GET (HttpGet) zum Abrufen von Inhalten und POST (HttpPost) zum Eingeben / Ändern von Inhalten einer Datenbank verwendet. Ich habe dies als Parameter an HttpPost gesendet und das PHP-Skript auf dem Webserver hat diese Parameter in SQL-Code konvertiert. Ist das eine RESTful App? Ich interessiere mich für ein Konzept, nicht dafür, wie gut das PHP-Skript gemacht wurde. Ich habe es nicht geschafft.

— DeviDave

2

Ich würde die Verwendung von PUT in dem Fall untersuchen, in dem Sie Inhalt ersetzen , dessen idiomatischerer REST als immer, wenn Sie POST verwenden.

— Martijn Verburg

Ja, in diesem Fall würde ich PUT verwenden.

— DeviDave

+1 für die Feststellung, dass GET korrekt implementiert werden muss (dh es ist idempotent). Ein solcher grundlegender Fehler in den Anfängen.

— Gary Rowe

@deviDave Möglicherweise möchten Sie sich auch PATCH ansehen, mit dem ein Teil einer Ressource aktualisiert werden kann. Wie Martin zu Recht betont, dient PUT dazu, die gesamte Ressource zu ersetzen.

— Gary Rowe

4

Bevor Sie fortfahren, kann Ihnen diese verwandte Frage helfen

Der Unterschied zwischen REST und RESTful ist einfach die Semantik. REST ist ein Architekturstil, der auf eine Client-Server-Beziehung angewendet wird. Mit RESTful können Sie Ihren Kunden einfach mitteilen, dass Sie REST verwenden.

Viele Webanwendungen behaupten, REST- konform zu sein, entsprechen jedoch nur teilweise den REST-Einschränkungen (wie auch Martijn Verburg in seiner Antwort erwähnt hat). Ich werde sie hier nur auflisten, aber ich rate Ihnen dringend, den Artikel zu lesen:

Kundenserver
Cachefähig
Geschichtetes System
Code auf Anfrage (optional)

Da Sie erwähnen, dass Sie auf der Clientseite arbeiten, kann es hilfreich sein zu sehen, was eine REST-Architektur von Ihnen als verbindendem Client verspricht und erwartet. Obwohl REST nicht HTTP ist, ist es bei weitem das beliebteste Protokoll, das REST unterstützt. Daher werde ich mein Beispiel darauf aufbauen.

Von Ihrem Kunden wird erwartet, dass er:

Verwenden Sie HTTP-Verben (z. B. GET, POST, PUT, DELETE, OPTIONS, PATCH), um relevante Operationen auszuführen
Annehmen von Headern und Verstehen von Content-Type-Headern (z. B. Sie erhalten XML, das Sie noch nie zuvor gesehen haben, können jedoch eine referenzierte XSD verwenden, um ein clientseitiges Domain-Modell zu erstellen, das Sie Ihrem Benutzer präsentieren können.)
Folgen Sie den angebotenen Links in einem von Ihnen verstandenen Inhaltstyp (z. B. lassen Sie Ihren Benutzer oder Ihre Anwendung daraus schließen, dass <link rel="pay" href="http://example.org/orders(1)/payment">HTML einen Statusübergang zum Erstellen einer Zahlungsressource durch einen POST mit einem Text aus XML ausdrückt, der die Zahlungsdetails wie die Kreditkartennummer darstellt , Menge und so weiter)
Reagieren Sie richtig auf die vielen verschiedenen HTTP-Statuscodes

Wenn dies der Fall ist, kann davon ausgegangen werden, dass es sich um einen REST-Client handelt, Sie möchten ihn möglicherweise als "RESTful-App" bezeichnen. Dies würde jedoch eher bedeuten, dass Sie REST auf der Clientseite verwenden der Begriff.

— Gary Rowe
quelle

3

RESTful bedeutet, dass die Schnittstelle eine Reihe von Objekten ist, die gelesen und aktualisiert (und möglicherweise gelöscht) werden können. Das heißt, es gibt keine Abfragen mit mehreren Parametern (der einzige Parameter ist das Objekt, das Sie lesen möchten), und es gibt nur einen Operationstyp, der etwas auf dem Server ändert, nämlich das Hochladen eines neuen Status.

Diese Einschränkungen stellen sicher, dass alle Anforderungen nicht vorübergehend sind (das mehrmalige Senden hat keine zusätzlichen Auswirkungen auf das einmalige Senden). Dies ist wichtig, da das Netzwerk möglicherweise jederzeit ausfällt und keine Anforderung oder Antwort übermittelt. Bei nicht vorübergehenden Anforderungen senden Sie es einfach erneut und müssen keine komplizierte Wiederherstellung durchführen.

— Jan Hudec
quelle

Upvote für den 1. Absatz. Also kurz und bündig. Vielen Dank!

— DeviDave

Noch etwas, um zu sehen, ob ich es richtig gemacht habe. Wenn ich (meine App) ein Client eines REST-Dienstes bin, kann ich als Client nicht feststellen, ob ein Dienst REST-fähig ist oder nicht, da meine Codierung immer dieselbe ist (httpget, httppost usw.). Dieses Prinzip ist nur für den Besitzer eines Server-Skripts / einer Server-App von Bedeutung.

— DeviDave

REST ist eine Richtlinie zum Entwerfen der Semantik der Schnittstelle. Die zugrunde liegende Technologie ist HTTP, unabhängig davon, ob die Schnittstelle REST-fähig ist oder nicht (andere Ebenen wie XML-RPC oder SOAP sind jedoch für REST-fähige Schnittstellen nicht relevant). Sie verwenden also immer dasselbe httpget, httppost usw. Sie behandeln Netzwerkfehler jedoch anders.

— Jan Hudec

Außerdem ist SMTP eine REST-fähige Schnittstelle. Sie verwendet jedoch andere Verben als GET, PUT usw. und ein anderes zugrunde liegendes Protokoll. Das Konzept ist dasselbe: Sie senden idempotente verbbasierte Befehle an einen Server.

— gbjbaanb

Nicht alle REST-Anforderungen sind idempotent. Wenn Sie beispielsweise einen POST mehrmals ausgeben, entstehen viele neue Ressourcen.

— Gary Rowe

REST vs RESTful vs "normaler" Webservice - das Gleiche oder nicht?