Frage Was genau ist RESTful Programmierung?


Was genau ist RESTful Programmierung?


3628
2018-03-22 14:45


Ursprung


Antworten:


Ein architektonischer Stil namens REST (Representative State Transfer) befürwortet, dass Web-Anwendungen HTTP so verwenden sollten, wie es war ursprünglich gedacht. Lookups sollten verwenden GET Anfragen. PUT, POST, und DELETE Anfragen sollte für verwendet werden Mutation, Erstellung bzw. Löschung.

REST-Befürworter neigen dazu, URLs wie z

http://myserver.com/catalog/item/1729

Die REST-Architektur benötigt diese "hübschen URLs" jedoch nicht. Eine GET-Anfrage mit einem Parameter

http://myserver.com/catalog?item=1729

ist jedes bisschen wie RESTful.

Beachten Sie, dass GET-Anfragen niemals zum Aktualisieren von Informationen verwendet werden sollten. Zum Beispiel eine GET-Anfrage zum Hinzufügen eines Artikels zu einem Einkaufswagen

http://myserver.com/addToCart?cart=314159&item=1729

wäre nicht angemessen. GET-Anfragen sollten sein idempotent. Das heißt, eine zweimalige Anfrage sollte sich nicht von der einmaligen Ausgabe unterscheiden. Das macht die Anforderungen im Cache speicherbar. Eine "In den Warenkorb" -Anfrage ist nicht idempotent. Wenn sie zweimal ausgegeben wird, werden zwei Kopien des Artikels in den Einkaufswagen gelegt. Eine POST-Anfrage ist in diesem Zusammenhang eindeutig angebracht. Also, sogar a REST-konforme Webanwendung benötigt seinen Anteil an POST-Anfragen.

Dies ist aus dem ausgezeichneten Buch entnommen Core JavaServer Faces Buch von David M. Geary.


540
2018-04-15 11:26



SICH AUSRUHEN ist das zugrunde liegende architektonische Prinzip des Webs. Das Erstaunliche am Web ist die Tatsache, dass Clients (Browser) und Server auf komplexe Weise interagieren können, ohne dass der Client vorher etwas über den Server und die Ressourcen weiß, die er hostet. Die Haupteinschränkung besteht darin, dass der Server und der Client sich beide auf die Übereinstimmung einigen müssen Medien verwendet, was im Falle des Webs ist HTML.

Eine API, die den Prinzipien von SICH AUSRUHEN Der Client muss nichts über die Struktur der API wissen. Stattdessen muss der Server alle Informationen bereitstellen, die der Client für die Interaktion mit dem Dienst benötigt. Ein HTML-Formular ist ein Beispiel dafür: Der Server gibt den Speicherort der Ressource und die erforderlichen Felder an. Der Browser weiß nicht im Voraus, wo die Informationen zu übermitteln sind, und er weiß nicht im Voraus, welche Informationen zu übermitteln sind. Beide Informationsformen werden vollständig vom Server bereitgestellt. (Dieses Prinzip wird genannt Hateonen: Hypermedia als die Engine des Anwendungsstatus.)

Also, wie trifft das zu? HTTPund wie kann es in der Praxis umgesetzt werden? HTTP orientiert sich an Verben und Ressourcen. Die zwei Verben im Mainstream-Gebrauch sind GET und POST, von denen ich denke, dass sie jeder erkennen wird. Der HTTP-Standard definiert jedoch mehrere andere wie PUT und DELETE. Diese Verben werden dann gemäß den Anweisungen des Servers auf Ressourcen angewendet.

Stellen wir uns beispielsweise vor, dass wir eine Benutzerdatenbank haben, die von einem Webdienst verwaltet wird. Unser Dienst verwendet eine benutzerdefinierte Hypermedia basierend auf JSON, für die wir den MIME-Typ zuweisen Anwendung / json + userdb (Es könnte auch eine sein Anwendung / xml + userdb und Anwendung / was auch immer + userdb - Viele Medientypen können unterstützt werden. Der Client und der Server wurden beide programmiert, um dieses Format zu verstehen, aber sie wissen nichts voneinander. Wie Roy Fielding weist darauf hin:

Eine REST-API sollte fast alle ihre beschreibenden Anstrengungen in Anspruch nehmen   Definieren der Medientypen, die zum Darstellen von Ressourcen und Fahren verwendet werden   Anwendungsstatus oder beim Definieren erweiterter Beziehungsnamen und / oder   Hypertext-aktiviertes Markup für vorhandene Standardmedientypen.

Eine Anfrage für die Basisressource / könnte etwas wie folgt zurückgeben:

Anfordern

GET /
Accept: application/json+userdb

Antwort

200 OK
Content-Type: application/json+userdb

{
    "version": "1.0",
    "links": [
        {
            "href": "/user",
            "rel": "list",
            "method": "GET"
        },
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

Aus der Beschreibung unserer Medien wissen wir, dass wir Informationen über verwandte Ressourcen aus Abschnitten finden können, die als "Links" bezeichnet werden. Das nennt man Hypermedia-Steuerelemente. In diesem Fall können wir anhand eines solchen Abschnitts feststellen, dass wir eine Benutzerliste finden, indem wir eine weitere Anfrage stellen /user:

Anfordern

GET /user
Accept: application/json+userdb

Antwort

200 OK
Content-Type: application/json+userdb

{
    "users": [
        {
            "id": 1,
            "name": "Emil",
            "country: "Sweden",
            "links": [
                {
                    "href": "/user/1",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/1",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/1",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        },
        {
            "id": 2,
            "name": "Adam",
            "country: "Scotland",
            "links": [
                {
                    "href": "/user/2",
                    "rel": "self",
                    "method": "GET"
                },
                {
                    "href": "/user/2",
                    "rel": "edit",
                    "method": "PUT"
                },
                {
                    "href": "/user/2",
                    "rel": "delete",
                    "method": "DELETE"
                }
            ]
        }
    ],
    "links": [
        {
            "href": "/user",
            "rel": "create",
            "method": "POST"
        }
    ]
}

Von dieser Antwort können wir viel erzählen. Zum Beispiel wissen wir jetzt, dass wir einen neuen Benutzer durch POST erstellen können /user:

Anfordern

POST /user
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Karl",
    "country": "Austria"
}

Antwort

201 Created
Content-Type: application/json+userdb

{
    "user": {
        "id": 3,
        "name": "Karl",
        "country": "Austria",
        "links": [
            {
                "href": "/user/3",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/3",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/3",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

Wir wissen auch, dass wir bestehende Daten ändern können:

Anfordern

PUT /user/1
Accept: application/json+userdb
Content-Type: application/json+userdb

{
    "name": "Emil",
    "country": "Bhutan"
}

Antwort

200 OK
Content-Type: application/json+userdb

{
    "user": {
        "id": 1,
        "name": "Emil",
        "country": "Bhutan",
        "links": [
            {
                "href": "/user/1",
                "rel": "self",
                "method": "GET"
            },
            {
                "href": "/user/1",
                "rel": "edit",
                "method": "PUT"
            },
            {
                "href": "/user/1",
                "rel": "delete",
                "method": "DELETE"
            }
        ]
    },
    "links": {
       "href": "/user",
       "rel": "list",
       "method": "GET"
    }
}

Beachten Sie, dass wir verschiedene HTTP-Verben (GET, PUT, POST, DELETE usw.) verwenden, um diese Ressourcen zu manipulieren, und dass das einzige Wissen, das wir für den Client vermuten, unsere Mediendefinition ist.

Weiterführende Literatur:

(Diese Antwort war Gegenstand einer gewissen Menge an Kritik, um den Punkt zu verfehlen. Dies war in den meisten Fällen eine faire Kritik. Was ich ursprünglich beschrieben habe, entsprach eher der Art und Weise, wie REST vor ein paar Jahren in der Regel umgesetzt wurde, als ich Zuerst habe ich das geschrieben und nicht seine wahre Bedeutung. Ich habe die Antwort überarbeitet, um die wahre Bedeutung besser darzustellen.)


2788
2018-03-22 19:37



RESTful Programmierung geht um:

  • Ressourcen werden durch eine persistente Kennung identifiziert: URIs sind heutzutage die allgegenwärtige Wahl der Kennung
  • Ressourcen, die mit einem gemeinsamen Satz von Verben manipuliert werden: HTTP-Methoden sind der übliche Fall - der ehrwürdige Create, Retrieve, Update, Delete wird POST, GET, PUT, und DELETE. Aber REST ist nicht auf HTTP beschränkt, es ist gerade der am häufigsten verwendete Transport.
  • Die tatsächliche Darstellung, die für eine Ressource abgerufen wird, hängt von der Anforderung und nicht vom Bezeichner ab: Verwenden Sie Header akzeptieren, um zu steuern, ob XML, HTTP oder sogar ein Java-Objekt die Ressource darstellen soll
  • Aufrechterhalten des Zustands im Objekt und Darstellen des Zustands in der Darstellung
  • Darstellung der Beziehungen zwischen Ressourcen in der Repräsentation der Ressource: Die Verknüpfungen zwischen Objekten sind direkt in die Repräsentation eingebettet
  • Ressourcenrepräsentationen beschreiben, wie die Repräsentation verwendet werden kann und unter welchen Umständen sie konsistent verworfen / erneut abgerufen werden sollte: Verwendung von HTTP-Cache-Control-Headern

Die letzte ist wahrscheinlich die wichtigste in Bezug auf die Konsequenzen und die allgemeine Wirksamkeit von REST. Insgesamt scheinen sich die meisten RESTful-Diskussionen auf HTTP und dessen Verwendung von einem Browser aus zu konzentrieren und was nicht. Ich verstehe, dass R. Fielding den Begriff prägte, als er die Architektur und die Entscheidungen beschrieb, die zu HTTP führten. In seiner Abschlussarbeit geht es mehr um die Architektur und Cache-Fähigkeit von Ressourcen als um HTTP.

Wenn Sie wirklich interessiert sind, was eine RESTful-Architektur ist und warum sie funktioniert, lesen Sie seine These ein paar Mal und lies die das ganze Ding nicht nur Kapitel 5! Als nächstes nachsehen Warum funktioniert DNS?. Lesen Sie über die hierarchische Organisation von DNS und wie Verweise funktionieren. Lesen Sie dann, wie das DNS-Caching funktioniert. Lesen Sie schließlich die HTTP-Spezifikationen (RFC2616 und RFC3040 insbesondere) und überlegen Sie, wie und warum das Caching so funktioniert, wie es funktioniert. Irgendwann wird es nur klicken. Die letzte Offenbarung für mich war, als ich die Ähnlichkeit zwischen DNS und HTTP sah. Danach beginnt zu verstehen, warum SOA und Message Passing Interfaces skalierbar sind.

Ich denke, dass der wichtigste Trick, um die architektonische Bedeutung und die Leistung Auswirkungen eines RESTful und zu verstehen Nichts geteilt Architekturen ist es, sich nicht an den Technologien und Implementierungsdetails hängen zu lassen. Konzentriere dich darauf, wer Ressourcen besitzt, wer für das Erstellen / Pflegen von Ressourcen verantwortlich ist, etc. Überlege dir dann die Repräsentationen, Protokolle und Technologien.


500
2017-07-04 05:47



So könnte es aussehen.

Erstellen Sie einen Benutzer mit drei Eigenschaften:

POST /user
fname=John&lname=Doe&age=25

Der Server antwortet:

200 OK
Location: /user/123

In Zukunft können Sie dann die Benutzerinformationen abrufen:

GET /user/123

Der Server antwortet:

200 OK
<fname>John</fname><lname>Doe</lname><age>25</age>

Um den Datensatz zu ändern (lname und age bleibt unverändert):

PATCH /user/123
fname=Johnny

Um den Datensatz zu aktualisieren (und folglich lname und age wird NULL sein):

PUT /user/123
fname=Johnny

392
2017-11-18 20:46



Ein tolles Buch über REST ist REST in der Praxis.

Muss gelesen werden Representative State Transfer (REST) und REST-APIs müssen hypertextgesteuert sein 

Siehe Martin Fowlers Artikel der Richardson Reifegradmodell (RMM) für eine Erklärung, was ein RESTful-Service ist.

Richardson Maturity Model

Um RESTful zu sein, muss ein Service die Anforderungen erfüllen Hypermedia als die Engine des Anwendungsstatus. (HATEOS)das heißt, es muss Level 3 in der RMM erreichen, lesen Sie den Artikel für Details oder die Dias aus dem Qcon-Talk.

Die HATEOAS-Einschränkung ist ein Akronym   für Hypermedia als Motor von   Anwendungsstatus Dieses Prinzip ist   das entscheidende Unterscheidungsmerkmal zwischen einem REST   und die meisten anderen Formen von Client-Server   System.

...

Ein Client einer RESTful-Anwendung benötigt   kennen nur eine einzige feste URL für den Zugriff   es. Alle zukünftigen Aktionen sollten sein   erkennbar von   Hypermedia-Links in der   Darstellungen der Ressourcen, die   werden von dieser URL zurückgegeben.   Standardisierte Medientypen sind auch   erwartet von jedem verstanden zu werden   Client, der möglicherweise eine RESTful-API verwendet.   (Aus Wikipedia, der freien Enzyklopädie)

REST Lackmus Test für Web Frameworks ist ein ähnlicher Reifetest für Web-Frameworks.

Annäherung an den reinen REST: Lernen, HATEOAS zu lieben ist eine gute Sammlung von Links.

REST versus SOAP für die öffentliche Cloud erörtert die aktuellen Ebenen der REST-Nutzung.

REST und Versionierung diskutiert Erweiterbarkeit, Versionierung, Evolvability usw.  durch Modifizierbarkeit


170
2018-03-22 15:20



Was ist REST?

REST steht für Representational State Transfer. (Es ist manchmal   "ReST" geschrieben.) Es beruht auf einem statuslosen, cache-fähigen Client-Server   Kommunikationsprotokoll - und in fast allen Fällen das HTTP   Protokoll wird verwendet.

REST ist ein Architekturstil zum Entwerfen von vernetzten Anwendungen.   Die Idee ist, dass, anstatt komplexe Mechanismen wie CORBA zu verwenden,   RPC oder SOAP, um zwischen Maschinen zu verbinden, wird einfaches HTTP verwendet   Anrufe zwischen Maschinen.

In vielerlei Hinsicht kann das World Wide Web selbst, basierend auf HTTP, betrachtet werden   als REST-basierte Architektur. RESTful-Anwendungen verwenden HTTP-Anforderungen   um Daten zu veröffentlichen (erstellen und / oder aktualisieren), Daten lesen (z. B. Abfragen durchführen),   und lösche Daten. Daher verwendet REST HTTP für alle vier CRUD   (Erstellen / Lesen / Aktualisieren / Löschen) Operationen.

REST ist eine leichte Alternative zu Mechanismen wie RPC (Remote   Prozeduraufrufe) und Webdienste (SOAP, WSDL, usw.). Später werden wir es tun   Sehen Sie, wie viel einfacher REST ist.

Trotz der Einfachheit ist REST voll ausgestattet; Es gibt grundsätzlich   Nichts, was Sie in Web Services tun können, was mit einem RESTful nicht möglich ist   die Architektur. REST ist kein "Standard". Es wird niemals ein W3C geben   Empfehlung zum Beispiel für REST. Und während es REST gibt   Programmier-Frameworks, die Arbeit mit REST ist so einfach, dass Sie können   oft "rollen Sie Ihre eigenen" mit Standard-Bibliothek Features in Sprachen wie   Perl, Java oder C #.

Eine der besten Referenzen, die ich gefunden habe, wenn ich versuche, die einfache wahre Bedeutung von Ruhe zu finden.

http://rest.elkstein.org/


128
2018-03-22 14:53



REST verwendet die verschiedenen HTTP-Methoden (hauptsächlich GET / PUT / DELETE), um Daten zu manipulieren.

Anstatt eine bestimmte URL zu verwenden, um eine Methode zu löschen /user/123/delete), würden Sie eine DELETE - Anfrage an die /user/[id] URL, um einen Benutzer zu bearbeiten, um Informationen zu einem Benutzer abzurufen, an den Sie eine GET-Anfrage senden /user/[id]

Zum Beispiel eine Reihe von URLs, die aussehen könnten wie einige der folgenden ..

GET /delete_user.x?id=123
GET /user/delete
GET /new_user.x
GET /user/new
GET /user?id=1
GET /user/id/1

Sie verwenden die HTTP "Verben" und haben ..

GET /user/2
DELETE /user/2
PUT /user

85
2017-07-12 16:33



Es ist Programmieren, wo die Architektur Ihres Systems passt REST-Stil angelegt von Roy Fielding in seine These. Da dies der Architekturstil ist, der das Web (mehr oder weniger) beschreibt, sind viele Leute daran interessiert.

Bonus-Antwort: Nein. Wenn Sie Software-Architektur nicht als akademisch studieren oder Web-Services entwerfen, gibt es wirklich keinen Grund, diesen Begriff gehört zu haben.


63
2018-03-23 17:11



Ich würde sagen, RESTful-Programmierung würde zum Erstellen von Systemen (API) dienen, die dem REST-Architekturstil folgen.

Ich fand dieses fantastische, kurze und leicht verständliche Tutorial über REST von Dr. M. Elkstein und zitierte den wesentlichen Teil, der Ihre Frage größtenteils beantworten würde:

Lerne REST: Ein Tutorial

REST ist ein Architektur Stil zum Gestalten von vernetzten Anwendungen.   Die Idee ist, dass, anstatt komplexe Mechanismen wie CORBA zu verwenden,   RPC oder SOAP, um zwischen Maschinen zu verbinden, wird einfaches HTTP verwendet   Anrufe zwischen Maschinen.

  • In vielerlei Hinsicht kann das World Wide Web selbst, basierend auf HTTP, als eine REST-basierte Architektur angesehen werden.

RESTful-Anwendungen verwenden HTTP-Anforderungen zum Veröffentlichen von Daten (create und / oder   aktualisieren), Daten lesen (z. B. Abfragen vornehmen) und Daten löschen. Also, RUHE   verwendet HTTP für alle vier CRUD-Operationen (Erstellen / Lesen / Aktualisieren / Löschen).

Ich glaube nicht, dass du dich dumm fühlen solltest, wenn du nicht von REST außerhalb von Stack Overflow hörst ..., ich wäre in der gleichen Situation !; Antworten auf diese andere SO Frage auf Warum wird REST jetzt groß? könnte einige Gefühle lindern.


43
2017-07-25 09:05



Ich entschuldige mich, wenn ich die Frage nicht direkt beantworte, aber es ist einfacher, all das mit detaillierteren Beispielen zu verstehen. Fielding ist aufgrund der Abstraktion und Terminologie nicht leicht zu verstehen.

Es gibt ein ziemlich gutes Beispiel hier:

Erklären REST und Hypertext: Spam-E der Spam-Reinigungsroboter

Und noch besser, es gibt eine saubere Erklärung mit einfachen Beispielen hier (der Powerpoint ist umfassender, aber Sie können das meiste davon in der HTML-Version bekommen):

http://www.xfront.com/REST.ppt oder http://www.xfront.com/REST.html

Nachdem ich die Beispiele gelesen hatte, konnte ich sehen, warum Ken sagt, dass REST hypertextgesteuert ist. Ich bin mir nicht wirklich sicher, dass er recht hat, denn das / user / 123 ist ein URI, der auf eine Ressource zeigt, und es ist mir nicht klar, dass es UNRESTful ist, nur weil der Client es "out-of-band" kennt.

Dieses xfront-Dokument erklärt den Unterschied zwischen REST und SOAP, und das ist auch sehr hilfreich. Wenn Fielding sagt: "Das ist RPC. Es schreit RPC."Es ist klar, dass RPC nicht REST-konform ist. Daher ist es nützlich, die genauen Gründe dafür zu sehen. (SOAP ist eine Art von RPC.)


43
2018-03-22 16:36



Was ist REST?

REST in offiziellen Worten, REST ist ein architektonischer Stil, der auf bestimmten Prinzipien aufbaut und die aktuellen "Web" -Fundamente verwendet. Es gibt 5 grundlegende Webgrundlagen, die zum Erstellen von REST-Diensten genutzt werden.

  • Prinzip 1: Alles ist eine Ressource Im REST-Architekturstil werden Daten und Funktionen als Ressourcen betrachtet. Der Zugriff erfolgt über URIs (Uniform Resource Identifiers), normalerweise Links im Web.
  • Prinzip 2: Jede Ressource wird durch einen eindeutigen Identifikator (URI) identifiziert
  • Prinzip 3: Verwenden Sie einfache und einheitliche Schnittstellen
  • Prinzip 4: Kommunikation wird durch Repräsentation gemacht
  • Prinzip 5: Sei staatenlos

36
2017-11-22 22:49