wake-up-neo.net

Was ist der Unterschied zwischen REST und HTTP-Protokolle?

Was ist das REST - Protokoll und was unterscheidet es vom HTTP-Protokoll?

30
Adham

REST ist ein Ansatz, der das HTTP-Protokoll nutzt und keine Alternative dazu ist.

Daten werden eindeutig über URL referenziert und können über HTTP-Vorgänge (GET, PUT, POST, DELETE usw.) verarbeitet werden. Eine Vielzahl von MIME-Typen wird für die Nachricht/Antwort unterstützt, XML und JSON sind jedoch am häufigsten.

Um beispielsweise Daten über einen Kunden zu lesen, können Sie eine HTTP-Get-Operation mit der URL http://www.example.com/customers/1 verwenden. Wenn Sie diesen Kunden löschen möchten, verwenden Sie einfach den HTTP-Löschvorgang mit derselben URL.

Der folgende Java-Code veranschaulicht, wie ein REST -Aufruf über das HTTP-Protokoll ausgeführt wird:

String uri =
    "http://www.example.com/customers/1";
URL url = new URL(uri);
HttpURLConnection connection =
    (HttpURLConnection) url.openConnection();
connection.setRequestMethod("GET");
connection.setRequestProperty("Accept", "application/xml");

JAXBContext jc = JAXBContext.newInstance(Customer.class);
InputStream xml = connection.getInputStream();
Customer customer =
    (Customer) jc.createUnmarshaller().unmarshal(xml);

connection.disconnect();

Für ein Java (JAX-RS) Beispiel siehe:

31
Blaise Doughan

REST ist ein Designstil für Protokolle. Er wurde von Roy Fielding in seiner Doktorarbeit entwickelt und formalisierte den Ansatz hinter HTTP/1.0. Er fand heraus, was gut mit ihm funktioniert, und nutzte dieses strukturierte Verständnis, um das Design von HTTP/Design zu beeinflussen. 1.1. Obwohl es in vielerlei Hinsicht nachträglich war, ist REST der Designstil hinter HTTP.

Die Dissertation von Fielding ist unter http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm zu finden und sehr lesenswert und auch lesbar. Dissertationen von Doktoranden können ziemlich hart sein, aber diese ist wunderbar gut beschrieben und für uns alle ohne vergleichbaren Informatiklevel gut lesbar. Es hilft, dass REST selbst ziemlich einfach ist; Es ist eines dieser Dinge, die offensichtlich sind, nachdem jemand anderes es erfunden hat. (In diesem Zusammenhang ist auch eine ganze Reihe von Dingen enthalten, die ältere Webentwickler auf eine einfache Art und Weise selbst erlernt haben, was das Lesen für viele zu einem großen "a ha!" - Moment machte).

Andere Protokolle auf Anwendungsebene sowie HTTP können auch REST verwenden, aber HTTP ist das klassische Beispiel.

Da HTTP REST verwendet, verwenden alle HTTP-Anwendungen ein REST System. Die Beschreibung einer Webanwendung oder eines Dienstes als RESTful oder nicht-RESTful bezieht sich darauf, ob REST davon Gebrauch macht oder dagegen arbeitet.

Das klassische Beispiel für ein RESTful-System ist eine "einfache" Website ohne Cookies (Cookies widersprechen REST nicht immer, sie können jedoch sein): Der Clientstatus wird geändert, indem der Benutzer auf einen Link klickt, der eine andere Seite lädt oder ein GET-Formular ausführt Abfragen, die Ergebnisse bringen. POST Formularabfragen können sowohl den Server- als auch den Clientstatus ändern (der Server führt etwas auf Basis des POST aus und sendet dann ein Hypertextdokument, das den neuen Status beschreibt). URIs beschreiben Ressourcen, aber die Entität (das Dokument), die sie beschreibt, kann sich je nach Inhaltstyp oder Sprache unterscheiden, die vom Benutzer bevorzugt wird. Schließlich war es für Browser immer möglich, die Seite selbst über PUT und DELETE zu aktualisieren, auch wenn dies bisher noch nicht üblich war und wenn jetzt etwas weniger ist.

Das klassische Beispiel eines nicht-REST-fähigen Systems, das HTTP verwendet, behandelt HTTP wie ein Transportprotokoll und sendet bei jeder Anforderung POST Daten an denselben URI, der dann in einem RPC-artige Weise, möglicherweise mit gemeinsamem Status der Verbindung.

Ein computerlesbares RESTful-System (dh keine Website in einem Browser, aber etwas, das programmgesteuert verwendet wird) würde Informationen über die von GETting URI betroffenen Ressourcen erhalten, die dann ein Dokument zurückgeben (z. B. in XML, aber nicht unbedingt), das den Status beschreibt der Ressource, einschließlich der URIs für verwandte Ressourcen (Hypermedia), ändern ihren Status durch PUTting-Entitäten, die den neuen Status beschreiben, oder DELETEing, und lassen andere Aktionen durch POSTing ausführen.

Hauptvorteile sind:

Skalierbarkeit: Das Fehlen eines gemeinsam genutzten Zustands führt zu einem viel skalierbareren System (dies wurde mir massiv demonstriert, als ich die Verwendung des Sitzungsstatus von einer stark betroffenen Website entfernte, während ich damit gerechnet hatte, dass es ein wenig zusätzliche Leistung, sogar eine Zeit-Anti-Session-Befürworter wie ich waren überwältigt von dem enormen Gewinn, der durch das Entfernen der ziemlich schlanken Nutzung von Sitzungen entstanden war, es war nicht einmal der Grund, warum ich sie entfernt hatte!)

Einfachheit: Es gibt verschiedene Wege, auf denen REST einfacher ist als mehr RPC-ähnliche Modelle, insbesondere gibt es nur wenige "Verben", die immer möglich sind, und es kann über jede Art von Ressource nachgedacht werden in vernünftiger Isolation zu den anderen.

Leichte Entitäten: Bei mehr RPC-ähnlichen Modellen enden die Entitäten oft in einer Vielzahl von Daten, nur um das RPC-ähnliche Modell wiederzugeben. Das ist nicht nötig. In der Tat ist manchmal ein einfaches Klartextdokument wirklich alles, was in einem bestimmten Fall wirklich benötigt wird. In diesem Fall müssten wir mit REST alles senden (obwohl dies nur ein Endergebnis wäre, da Text ist nicht mit verwandten Ressourcen verknüpft. Ein anderes klassisches Beispiel ist die Anforderung, eine Image-Datei zu erhalten. RPC-ähnliche Modelle müssen sie normalerweise in ein anderes Format einwickeln und möglicherweise auf irgendeine Weise kodieren, damit sie im übergeordneten Format gespeichert wird (z. B. wenn das RPC-ähnliche Modell XML verwendet (Das Bild muss eine Base-64 sein oder ähnlich sein, um in gültiges XML zu passen). Ein RESTful-Modell überträgt die Datei genauso wie einen Browser.

Vom Menschen lesbare Ergebnisse: Nicht unbedingt so, aber es ist oft einfach, einen RESTful-Webservice zu erstellen, bei dem die Ergebnisse relativ gut lesbar sind, was das Debuggen und die Entwicklung ohne Ende unterstützt. Ich habe sogar eine erstellt, bei der ein XSLT bedeutet, dass das Ganze von Menschen als (relativ grobe) Website genutzt werden kann, obwohl es nicht in erster Linie für den menschlichen Gebrauch gedacht war (im Wesentlichen diente das XSLT als Client, um es vorzustellen Benutzer, es war nicht einmal in der Spezifikation, nur um meine eigene Entwicklung zu erleichtern!).Lockere Bindung zwischen Server und Client: Dies führt zu einer einfacheren späteren Entwicklung oder zu Änderungen beim Hosting des Systems. Wenn Sie sich an das Hypertext-Modell halten, können Sie die gesamte Struktur ändern, einschließlich des Wechsels von einem einzelnen Host zu mehreren Hosts für verschiedene Dienste, ohne den Client-Code zu ändern.

Caching: Für die GET-Vorgänge, bei denen der Client Informationen über den Status einer Ressource erhält, lassen die standardmäßigen HTTP-Caching-Mechanismen beide Anweisungen zu, die die Ressource frühestens zu einem bestimmten Datum sinnvoll ändert (bis dahin ist keine Abfrage erforderlich.) ) oder dass es sich seit der letzten Abfrage nicht geändert hat (senden Sie ein paar hundert Bytes von Headern, die dies sagen, und nicht mehrere Kilobytes an Daten). Die Verbesserung der Leistung kann immens sein (groß genug, um die Leistung eines Objekts von dem Punkt aus zu verschieben, an dem die Verwendung nicht praktikabel ist, bis zu dem Punkt, an dem Leistung in manchen Fällen kein Problem mehr darstellt).

Verfügbarkeit von Toolkits: Da es auf einer relativ einfachen Ebene funktioniert, können Sie, wenn Sie über einen Webserver verfügen, einen RESTful-Systemserver erstellen, und wenn Sie über eine Art HTTP-Client-API verfügen (XHR in Browser-Javascript, HttpWebRequest in .NET usw.) Erstellen Sie den Client eines RESTful-Systems.

Resilienz: Insbesondere bedeutet das Fehlen eines gemeinsam genutzten Zustands, dass ein Client sterben und wieder in Betrieb gehen kann, ohne dass der Server dies weiß, und sogar der Server kann sterben und wieder verwendet werden, ohne dass der Client dies weiß. Offensichtlich schlägt die Kommunikation in diesem Zeitraum fehl, aber sobald der Server wieder online ist, kann alles so weitergehen wie bisher. Dies vereinfacht auch die Verwendung von Webfarmen im Hinblick auf Redundanz und Leistung. Jeder Server verhält sich so, als wäre er der einzige Server, und es spielt keine Rolle, dass er eigentlich nur einen Bruchteil der Anforderungen eines bestimmten Clients bearbeitet.

Resiliance: In particular, the lack of shared state means that a client can die and come back into use without the server knowing, and even the server can die and come back into use without the client knowing. Obviously communications during that period will fail, but once the server is back online things can just continue as they were. This also really simplifies the use of web-farms for redundancy and performance - each server acts like it's the only server there is, and it doesn't matter that its actually only dealing with a fraction of the requests from a given client.

35
Jon Hanna

REST ist kein Protokoll, sondern eine verallgemeinerte Architektur für die Beschreibung einer zustandslosen Client-Server-Plattform mit verteilter Medien. Eine REST - Architektur kann unter Verwendung einer Reihe verschiedener Kommunikationsprotokolle implementiert werden, obwohl HTTP bei weitem die häufigste ist.

10
aroth

REST ist kein Protokoll, es ist eine Möglichkeit, Ihre Anwendung bereitzustellen, meist über HTTP. 

sie möchten beispielsweise eine API Ihrer Anwendung, die getClientById verwendet, verfügbar machen
anstatt eine URL zu erstellen 

yourapi.com/getClientById?id=4
du kannst tun
yourapi.com/clients/id/4 

da Sie eine GET-Methode verwenden, bedeutet dies, dass Sie Daten abrufen möchten 

Sie nutzen die HTTP-Methoden: GET/DELETE/PUT
yourapi.com/clients/id/4 kann auch mit delete umgehen, wenn Sie eine delete-Methode und nicht GET senden, was bedeutet, dass Sie den Datensatz deketieren möchten 

4
fatnjazzy

Alle Antworten sind gut.

Hiermit füge ich eine ausführliche Beschreibung von REST hinzu und wie er HTTP verwendet.

REST = Representational State Transfer

REST ist eine Reihe von Regeln, mit deren Hilfe Sie eine verteilte Anwendung erstellen können, die über bestimmte wünschenswerte Einschränkungen verfügt.

Es ist zustandslos, dh im Idealfall sollte keine Verbindung zwischen Client und Server bestehen. 

Es liegt in der Verantwortung des Clients, seinen Kontext an den Server zu übergeben, und der Server kann diesen Kontext speichern, um die weitere Anforderung des Clients zu verarbeiten. Die vom Server gewartete Sitzung wird beispielsweise durch die vom Client übergebene Sitzungskennung identifiziert.

Vorteile der Staatenlosigkeit:

  1. Web Services können jeden Methodenaufruf separat behandeln.
  2. Web Services müssen die vorherige Interaktion des Clients nicht aufrechterhalten.
  3. Dies vereinfacht wiederum das Anwendungsdesign.
  4. HTTP ist im Gegensatz zu TCP selbst ein zustandsloses Protokoll. RESTful Web Services arbeiten daher nahtlos mit den HTTP-Protokollen.

Nachteile von Staatenlosigkeit: 

  1. Zu jeder Anfrage muss eine zusätzliche Ebene in Form von Überschriften hinzugefügt werden, um den Status des Clients zu erhalten.
  2. Aus Sicherheitsgründen müssen wir möglicherweise zu jeder Anfrage eine Header-Information hinzufügen.

HTTP-Methoden, die von REST unterstützt werden:

GET: /string/someotherstring:
Es ist idempotent (bedeutet, dass mehrere Anrufe jedes Mal die gleichen Ergebnisse zurückgeben sollen) und idealerweise bei jedem Anruf die gleichen Ergebnisse liefern

STELLEN:
.__ wie GET. Idempotent und wird verwendet, um Ressourcen zu aktualisieren.

POST: sollte eine URL und einen Körper enthalten
Wird zum Erstellen von Ressourcen verwendet. Mehrere Anrufe sollten im Idealfall unterschiedliche Ergebnisse liefern und mehrere Produkte erstellen.

LÖSCHEN:
Zum Löschen von Ressourcen auf dem Server. 

KOPF: 

Die Methode HEAD ist mit GET identisch, mit der Ausnahme, dass der Server KEINEN Nachrichtentext in der Antwort zurückgeben darf. Die Metadaten, die in den HTTP-Headern als Antwort auf eine HEAD -Anfrage enthalten sind, sollten identisch sein mit den Informationen, die als Antwort auf eine GET-Anfrage gesendet wurden.

OPTIONEN: 

Mit dieser Methode kann der Client die mit einer Ressource verknüpften Optionen und/oder Anforderungen oder die Fähigkeiten eines Servers ermitteln, ohne dass eine Ressourcenaktion impliziert oder ein Ressourcenabruf initiiert wird.

HTTP-Antworten

Hier geht es zu allen Antworten

Hier sind einige wichtige:
200 - OK
3XX - Zusätzliche Informationen, die von der Client- und URL-Weiterleitung benötigt werden
400 - Schlechte Anfrage
401 - Unbefugter Zugriff
403 Verboten
Die Anfrage war gültig, aber der Server lehnt die Aktion ab. Der Benutzer verfügt möglicherweise nicht über die erforderlichen Berechtigungen für eine Ressource oder benötigt ein Konto.

404 Nicht gefunden
Die angeforderte Ressource konnte nicht gefunden werden, ist jedoch möglicherweise in der Zukunft verfügbar. Nachträgliche Anfragen des Auftraggebers sind zulässig.

405 - Methode nicht zulässig Eine Anforderungsmethode wird für die angeforderte Ressource nicht unterstützt. B. eine GET-Anforderung in einem Formular, für die Daten per POST angezeigt werden müssen, oder eine PUT-Anforderung in einer Nur-Lese-Ressource.

404 - Anfrage nicht gefunden
500 - Interner Serverfehler
502 - Fehler beim Gateway 

0
Pritam Banerjee