it-swarm.com.de

Was ist der Unterschied zwischen HTTP und REST?

Nachdem ich viel über die Unterschiede zwischen REST und SOAP gelesen hatte, bekam ich den Eindruck, dass REST nur ein anderes Word für HTTP ist. Kann jemand erklären, welche Funktionalität REST zu HTTP hinzufügt?

Hinweis: Ich suche keinen Vergleich von REST mit SOAP.

Aktualisieren: Danke für deine Antworten. Nun ist mir klar geworden, dass REST nur eine Reihe von Regeln für die Verwendung von HTTP ist. Daher habe ich ein Follow-up zu was sind die Vorteile dieser Konventionen .

Hinweis: Ich verstehe jetzt die Bedeutung von REST; Als Emil Ivanov Bemerkungen bedeutet REST, HTTP so zu verwenden, wie es sein soll. Ich bin mir jedoch nicht sicher, ob dies einen eigenen Begriff verdient, und ich bekomme den Hype sicherlich nicht.

237
Dimitri C.

Nein,RESTist der WegHTTPsollte verwendet sein. 

Heute verwenden wir nur ein kleines bisschen der Methoden des HTTP-Protokolls - nämlich GET und POST. Die Methode REST besteht darin, alle Methoden des Protokolls zu verwenden.

Beispielsweise schreibt REST die Verwendung von DELETE zum Löschen eines Dokuments (Datei, Status usw.) hinter einer URI vor, während Sie mit HTTP eine GET- oder POST-Abfrage wie ...product/?delete_id=22 missbrauchen würden.

176
aefxx

HTTP ist ein für die Kommunikation verwendetes Protokoll, das normalerweise zur Kommunikation mit Internetressourcen oder einer Anwendung mit einem Webbrowser-Client verwendet wird.

REST bedeutet, dass das Hauptkonzept, das Sie beim Entwerfen der Anwendung verwenden, die Ressource ist: Für jede Aktion, die Sie ausführen möchten, müssen Sie eine Ressource definieren, für die Sie normalerweise nur die CRUD-Operation ausführen. Dies ist eine einfache Aufgabe. Daher ist es sehr praktisch, 4 Verben zu verwenden, die im HTTP-Protokoll für die 4 CRUD-Vorgänge verwendet werden (Get for Read, POST ist für CREATE, PUT für UPDATE und DELETE für DELETE.) Konzept des RPC (Remote Procedure Call), bei dem Sie eine Reihe von Aktionen haben, die Sie als Ergebnis eines Anrufs des Benutzers ausführen möchten. Wenn Sie beispielsweise darüber nachdenken, wie Sie ein Facebook wie in einem Beitrag beschreiben, können Sie mit RPC Dienste erstellen, die als AddLikeToPost und RemoveLikeFromPost bezeichnet werden, und diese zusammen mit all Ihren anderen Diensten, die sich auf FB-Beiträge beziehen, verwalten Objekt für Like. Mit REST haben Sie ein Like-Objekt, das mit den Funktionen Delete und Create separat verwaltet wird. Es bedeutet auch, dass es eine separate Entität in Ihrer Datenbank beschreibt. das sieht vielleicht nach einem kleinen Unterschied aus, aber so zu arbeiten, würde normalerweise einen viel einfacheren Code und eine viel einfachere Anwendung ergeben. Mit diesem Design ist die Logik der App in der Struktur des Objekts (Modell) offensichtlich. Im Gegensatz zu RPC, mit dem Sie normalerweise explizit viel mehr Logik hinzufügen müssen.

das Entwickeln einer RESTful-Anwendung ist in der Regel viel schwieriger, da Sie komplizierte Dinge auf einfache Weise beschreiben müssen. Es ist schwierig, alle Funktionalitäten nur mit CRUD-Funktionen zu beschreiben, aber danach wäre Ihr Leben viel einfacher und Sie werden feststellen, dass Sie viel kürzere Methoden schreiben werden.

Eine weitere beschränkte REST -Architektur besteht darin, bei der Kommunikation mit dem Client (zustandslos) nicht den Sitzungskontext zu verwenden. Dies bedeutet, dass alle Informationen benötigt werden, um zu verstehen, wer der Client ist und was er wünscht, mit der Webnachricht weitergeleitet wird. Jeder Aufruf einer Funktion ist selbstbeschreibend. Es gibt keine vorherige Konversation mit dem Client, auf die in der Nachricht verwiesen werden kann. Daher konnte ein Client Ihnen nicht sagen "Gib mir die nächste Seite", da Sie keine Sitzung zum Speichern der vorherigen Seite haben und welche Art von Seite Sie möchten, der Client müsste sagen: "Mein Name ist Yuval Seite 2 eines bestimmten Beitrags in einem bestimmten Forum ". Das bedeutet, dass in der Kommunikation etwas mehr Daten übertragen werden müssten. Denken Sie jedoch an den Unterschied zwischen dem Finden eines Fehlers, der von der Funktion "Nächste Seite herunterladen" gemeldet wird, im Gegensatz zu "Holen Sie sich die Seite 2 der Frage Nr. 2190836 im Stapelüberlauf".

Natürlich steckt viel mehr dahinter, aber meiner Meinung nach sind dies die Hauptkonzepte eines Teelöffels.

70
Yuval Perelman

REST fügt HTTP keine spezifische Funktionalität hinzu, sondern ist ein Architekturstil, der neben HTTP entwickelt wurde und meistens HTTP für das Protokoll der Anwendungsebene verwendet.

50
Mark

HTTP ist ein Anwendungsprotokoll. REST ist eine Reihe von Regeln, mit deren Hilfe Sie eine verteilte Anwendung mit bestimmten wünschenswerten Einschränkungen erstellen können.

Wenn Sie nach den wichtigsten Einschränkungen von REST suchen, die eine RESTful-Anwendung von jeder beliebigen HTTP-Anwendung unterscheiden, würde ich die Einschränkung "Selbstbeschreibung" und die Hypermedia-Einschränkung (auch als "Engine of Application State" bezeichnet) bezeichnen. HATEOAS)) sind die wichtigsten.

Die Selbstbeschreibungsbeschränkung erfordert, dass eine RESTful-Anforderung in der Absicht des Benutzers vollständig selbstbeschreibend ist. Auf diese Weise können Zwischenhändler (Proxys und Caches) sicher auf die Nachricht reagieren. 

Bei der HATEOAS-Einschränkung geht es darum, Ihre Anwendung in ein Link-Web zu verwandeln, bei dem der aktuelle Status des Clients auf seinem Platz in diesem Web basiert. Es ist ein kniffliges Konzept und benötigt mehr Zeit zum Erklären als ich es jetzt habe.

25
Darrel Miller

Nicht ganz...

http://en.wikipedia.org/wiki/Representational_State_Transfer

REST wurde ursprünglich in der .__ beschrieben. HTTP-Kontext, ist jedoch nicht auf .__ beschränkt. dieses Protokoll. RESTful-Architekturen kann auf einer anderen Anwendung basieren Schichtprotokolle, wenn sie bereits __. sorgen für ein reichhaltiges und einheitliches Vokabular für Anwendungen, die auf der Übertragung basieren von bedeutungsvollem repräsentativem Zustand . RESTful-Anwendungen maximieren die Verwendung der bereits vorhandenen, genau definierten Schnittstelle und andere integrierte Fähigkeiten, die vom ausgewählten .__ bereitgestellt werden. Netzwerkprotokoll und minimieren die Hinzufügen neuer anwendungsspezifischer Features darüber.

http://www.looselycoupled.com/glossary/SOAP

(Simple Object Access Protocol) Das Standard für Webservicemeldungen . Basierend auf XML definiert SOAP einen Umschlag Format und verschiedene Regeln für seinen Inhalt beschreiben. Gesehen (mit WSDL und UDDI) als einer der drei Grundlagen für Webdienste, es ist das bevorzugte Protokoll für Austausch von Webdiensten, jedoch nicht bedeutet die einzige; Befürworter von REST sagen, dass es unnötig fügt Komplexität.

13
LiamB

Soweit ich es verstehe, erzwingt REST die Verwendung der verfügbaren HTTP-Befehle, da sie verwendet werden sollten.

Zum Beispiel könnte ich Folgendes tun:

GET
http://example.com?method=delete&item=xxx

Im Ruhezustand würde ich jedoch die Anforderungsmethode "DELETE" verwenden, wodurch der Abfrageparameter "method" entfällt

DELETE
http://example.com?item=xxx
10
Dss

REST ist eine spezielle Methode, um sich dem Design großer Systeme (wie dem Web) zu nähern.

Es ist ein Satz von Regeln (oder Einschränkungen).

HTTP ist ein Protokoll, das versucht, diese Regeln einzuhalten.

7
Mike

HTTP ist ein Kommunikationsprotokoll, das Nachrichten über ein Netzwerk transportiert. SOAP ist ein Protokoll zum Austausch von XML-basierten Nachrichten, das HTTP zum Transportieren dieser Nachrichten verwenden kann. Rest ist ein Protokoll zum Austausch von (XML- oder JSON-Nachrichten) das kann HTTP verwenden, um diese Nachrichten zu transportieren.

4
vamsi

RESTist nicht unbedingt anHTTPgebunden. RESTful-Webdienste sind nur Webdienste, die einer RESTful-Architektur folgen.

What is Rest -
1- Client-server
2- Stateless
3- Cacheable
4- Layered system
5- Code on demand
6- Uniform interface
3
Rahul Patel

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.

REST ist ein Protokoll zum Austausch von Nachrichten (XML, JSON usw.), die HTTP zum Transportieren dieser Nachrichten verwenden können.

Eigenschaften:

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 Anfrage 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 jeder Anfrage eine Header-Info hinzufügen.

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

GET:/string/someotherstring Es ist idempotent und sollte im Idealfall bei jedem Anruf die gleichen Ergebnisse zurückgeben

PUT: Gleich 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.

DELETE: 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 Metainformationen, 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 vom Client und der URL-Weiterleitung benötigt werden 400 - Fehlerhafte Anforderung
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 wurde nicht gefunden, 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 

2
Pritam Banerjee

Von Sie kennen den Unterschied zwischen HTTP und REST nicht

Die Architektur von REST und das HTTP 1.1-Protokoll sind also unabhängig voneinander andere, aber das HTTP 1.1-Protokoll wurde als ideales Protokoll für .__ gebaut. Folgen Sie den Prinzipien und Einschränkungen von REST. Eine Möglichkeit, die Die Beziehung zwischen HTTP und REST besteht darin, dass REST der Entwurf ist, und HTTP 1.1 ist eine Implementierung dieses Designs.

1
Farsan Rashid

HTTP is a contract, a communication protocol and REST is a concept, an architectural style kann HTTP, FTP oder andere Kommunikationsprotokolle verwenden, wird aber häufig mit HTTP verwendet.

REST implies a series of constraints about how Server and Client should interact. HTTP is a communication protocol with a given mechanism for server-client data transfer wird am häufigsten in der API REST verwendet, nur weil REST was inspired by WWW (world wide web) which largely used HTTP vor REST definiert wurde. Daher ist es einfacher, den API-Stil REST mit HTTP zu implementieren.

There are three major constraints in REST (but there are more):

1. Die Interaktion zwischen Server und Client sollte nur über Hypertext beschrieben werden.

2. Server und Client sollten lose miteinander gekoppelt sein und keine gegenseitigen Annahmen treffen. Der Client sollte nur den Einstiegspunkt für Ressourcen kennen. Interaktionsdaten sollten vom Server in der Antwort bereitgestellt werden.

3. Der Server sollte keine Informationen zum Anforderungskontext speichern. Anforderungen müssen unabhängig und idempotent sein (dh wenn dieselbe Anfrage unendlich oft wiederholt wird, wird genau dasselbe Ergebnis abgerufen).

Und HTTP ist nur ein Kommunikationsprotokoll (ein Werkzeug), das dazu beitragen kann.

Weitere Informationen finden Sie unter diesen Links:

https://martinfowler.com/articles/richardsonMaturityModel.htmlhttp://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

0
Daniel

REST APIs müssen hypertextgesteuert sein

Von Roy Fieldings Blog Hier können Sie überprüfen, ob Sie eine HTTP-API oder eine REST -API erstellen:

API-Designer beachten Sie bitte die folgenden Regeln, bevor Sie Ihre Erstellung als REST - API aufrufen:

  • Eine REST - API sollte nicht von einem einzelnen Kommunikationsprotokoll abhängig sein, obwohl ihre erfolgreiche Zuordnung zu einem bestimmten Protokoll von der Verfügbarkeit von Metadaten, der Wahl der Methoden usw. abhängig sein kann. Im Allgemeinen jedes Protokollelement, das einen URI verwendet Zur Identifizierung muss es möglich sein, dass ein URI-Schema für diese Identifikation verwendet wird. [Misserfolg hier bedeutet, dass die Identifikation nicht von der Interaktion getrennt ist.]
  • Eine REST - API sollte keine Änderungen an den Kommunikationsprotokollen enthalten, abgesehen vom Ausfüllen oder Korrigieren der Details von untergeordneten Bits von Standardprotokollen, z. B. der PATCH-Methode von HTTP oder dem Link-Header-Feld. Problemumgehungen für fehlerhafte Implementierungen (z. B. solche Browser, die dumm genug sind, um zu glauben, dass HTML den HTTP-Methodensatz definiert), sollten separat oder zumindest in Anhängen definiert werden, mit der Erwartung, dass die Problemumgehung letztendlich veraltet ist. [Fehler hier bedeutet, dass die Ressourcenschnittstellen objektspezifisch und nicht generisch sind.]
  • Eine REST - API sollte fast ihren gesamten beschreibenden Aufwand aufwenden, um die Medientypen zu definieren, die für die Darstellung von Ressourcen und den Status der Anwendung verwendet werden, oder um erweiterte Beziehungsnamen und/oder hypertextfähige Markierungen für vorhandene Standards zu definieren Medientypen. Jede Anstrengung, die beschrieben wird, welche Methoden für welche URIs von Interesse verwendet werden sollen, sollte vollständig im Rahmen der Verarbeitungsregeln für einen Medientyp (und in den meisten Fällen bereits durch vorhandene Medientypen definiert) definiert werden. [Misserfolg hier bedeutet, dass Out-of-Band-Informationen anstelle von Hypertext die Interaktion antreiben.]
  • Eine REST - API darf keine festen Ressourcennamen oder -hierarchien definieren (eine offensichtliche Kopplung von Client und Server). Server müssen die Freiheit haben, ihren eigenen Namespace zu steuern. Ermöglichen Sie Servern stattdessen, Clients zu instruieren, wie geeignete URIs erstellt werden sollen, beispielsweise in HTML-Formularen und URI-Vorlagen, indem diese Anweisungen in Medientypen und Verknüpfungsbeziehungen definiert werden. [Fehler hier bedeutet, dass Kunden eine Ressourcenstruktur aufgrund von Out-of-Band-Informationen annehmen, wie z. B. einen domänenspezifischen Standard, der das datenorientierte Äquivalent zur funktionalen Kopplung von RPC darstellt].
  • Eine REST - API sollte niemals "typisierte" Ressourcen haben, die für den Client von Bedeutung sind. Spezifikationsautoren können Ressourcentypen verwenden, um die Serverimplementierung hinter der Schnittstelle zu beschreiben. Diese Typen müssen jedoch für den Client irrelevant und unsichtbar sein. Die einzigen Typen, die für einen Kunden von Bedeutung sind, sind der Medientyp der aktuellen Darstellung und standardisierte Beziehungsnamen. [dito]
  • 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.]
0
icc97