Was genau ist RESTful-Programmierung?

Question

Was genau ist RESTful-Programmierung?

Answer 1

REST ist das grundlegende 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 im Voraus etwas über den Server und die von ihm gehosteten Ressourcen weiß. Die wichtigste Voraussetzung dafür ist, dass Server und Client sich über die Medien verwendet, die im Falle des Webs HTML .

Eine API, die sich an die Grundsätze der REST setzt nicht voraus, dass der Client etwas über die Struktur der API weiß. Vielmehr muss der Server alle Informationen bereitstellen, die der Client benötigt, um mit dem Dienst zu interagieren. Eine 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, wohin er die Informationen übermitteln soll, und er weiß nicht im Voraus, welche Informationen er übermitteln soll. Beide Arten von Informationen werden vollständig vom Server bereitgestellt. (Dieses Prinzip wird als HATEOAS : Hypermedia als Motor des Anwendungsstatus .)

Was bedeutet das nun für HTTP und wie kann sie in der Praxis umgesetzt werden? HTTP ist auf Verben und Ressourcen ausgerichtet. Die beiden gebräuchlichsten Verben sind GET y POST die, wie ich glaube, jeder erkennen wird. Der HTTP-Standard definiert jedoch einige andere, wie z. B. PUT y DELETE . Diese Verben werden dann gemäß den Anweisungen des Servers auf die Ressourcen angewendet.

Nehmen wir zum Beispiel an, dass wir eine Benutzerdatenbank haben, die von einem Webdienst verwaltet wird. Unser Dienst verwendet eine benutzerdefinierte Hypermedia auf der Grundlage von JSON, für die wir den Mimetyp application/json+userdb (Möglicherweise gibt es auch eine application/xml+userdb y application/whatever+userdb - viele Medientypen können unterstützt werden). Sowohl der Client als auch der Server wurden so programmiert, dass sie dieses Format verstehen, aber sie wissen nichts voneinander. Als Roy Fielding weist darauf hin:

Eine REST-API sollte fast ihren gesamten Beschreibungsaufwand in Definition des Medientyps/der Medientypen, der/die zur Darstellung von Ressourcen und zur Steuerung des Anwendungsstatus verwendet werden, oder in der Definition von erweiterten Beziehungsnamen und/oder hypertextfähigen Markups für bestehende Standardmedientypen.

Eine Anfrage für die Basisressource / könnte etwa so aussehen:

Anfrage

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 in Abschnitten mit der Bezeichnung "Links" finden können. Dies wird als Hypermedia-Kontrollen . In diesem Fall können wir aus einem solchen Abschnitt erkennen, dass wir eine Benutzerliste finden können, indem wir eine weitere Anfrage für /user :

Anfrage

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"
        }
    ]
}

Aus dieser Antwort können wir viel ablesen. Zum Beispiel wissen wir jetzt, dass wir einen neuen Benutzer erstellen können, indem wir POST in Bezug auf /user :

Anfrage

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 vorhandene Daten ändern können:

Anfrage

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 verwenden ( GET , PUT , POST , DELETE usw.), um diese Ressourcen zu manipulieren, und dass das einzige Wissen, das wir auf Seiten des Kunden voraussetzen, unsere Mediendefinition ist.

Lesen Sie weiter:

• Die vielen viel besseren Antworten auf dieser Seite.
• Wie ich meiner Frau REST erklärt habe .
• Wie ich meiner Frau REST erklärt habe .
• Martin Fowler's Gedanken
• Die API von PayPal verfügt über Hypermedia-Kontrollen

(An dieser Antwort wurde viel Kritik geübt, weil sie den Kern der Sache nicht trifft. Im Großen und Ganzen ist das eine berechtigte Kritik. Was ich ursprünglich beschrieben habe, entsprach eher der Art und Weise, wie REST vor ein paar Jahren, als ich dies zum ersten Mal schrieb, üblicherweise implementiert wurde, als seiner wahren Bedeutung. Ich habe die Antwort überarbeitet, um die wahre Bedeutung besser darzustellen).

Answer 2

Eine Baustil genannt. REST (Repräsentative Zustandsübertragung) befürwortet, dass Webanwendungen HTTP verwenden sollten, wie es früher ursprünglich angedacht . Nachschlagen sollte mit GET Anfragen. PUT , POST y DELETE Anfragen sollte verwendet werden für Mutation , Erstellung y Löschung beziehungsweise.

REST-Befürworter neigen dazu, URLs zu bevorzugen, wie z. B.

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

aber die REST-Architektur erfordert diese "hübschen URLs" nicht. Eine GET-Anfrage mit einem Parameter

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

ist genau so RESTful.

Beachten Sie, dass GET-Anfragen niemals zur Aktualisierung von Informationen verwendet werden sollten. Eine GET-Anfrage zum Hinzufügen eines Artikels zu einem Einkaufswagen wäre zum Beispiel

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

wäre nicht angemessen. GET-Anfragen sollten sein idempotent . Das heißt, eine Anfrage zweimal zu stellen, sollte sich nicht von einer einmaligen Anfrage unterscheiden. Das macht die Anfragen cachefähig. Eine "In den Warenkorb"-Anforderung ist nicht idempotent - wenn sie zweimal gestellt wird, werden dem Warenkorb zwei Kopien des Artikels hinzugefügt. Eine POST-Anforderung ist in diesem Zusammenhang eindeutig angemessen. Daher kann auch eine RESTful-Webanwendung braucht seinen Anteil an POST-Anfragen.

Dies stammt aus dem ausgezeichneten Buch Kern-JavaServer-Gesichter Buch von David M. Geary.

Answer 3

Bei der RESTful-Programmierung geht es um:

• Ressourcen, die durch einen dauerhaften Bezeichner identifiziert werden: URIs sind heutzutage die allgegenwärtige Wahl des Bezeichners
• Ressourcen, die mit einem gemeinsamen Satz von Verben manipuliert werden: HTTP-Methoden sind der am häufigsten anzutreffende Fall - die altehrwürdige Create , Retrieve , Update , Delete wird POST , GET , PUT y DELETE . REST ist jedoch nicht auf HTTP beschränkt, es ist nur der derzeit am häufigsten verwendete Transportweg.
• die tatsächliche Darstellung, die für eine Ressource abgerufen wird, hängt von der Anfrage und nicht vom Bezeichner ab: verwenden Sie Accept-Header, um zu steuern, ob Sie XML, HTTP oder sogar ein Java-Objekt als Darstellung der Ressource wünschen
• Beibehaltung des Zustands im Objekt und Darstellung des Zustands in der Repräsentation
• Darstellung der Beziehungen zwischen Ressourcen in der Darstellung der Ressource: die Verbindungen zwischen Objekten sind direkt in die Darstellung eingebettet
• Ressourcendarstellungen beschreiben, wie die Darstellung verwendet werden kann und unter welchen Umständen sie auf konsistente Weise verworfen/zurückgeholt werden sollte: Verwendung von HTTP Cache-Control-Headern

Der letzte Punkt ist wahrscheinlich der wichtigste im Hinblick auf die Folgen und die allgemeine Wirksamkeit von REST. Insgesamt scheinen sich die meisten REST-Diskussionen auf HTTP und seine Verwendung in einem Browser zu konzentrieren. Soweit ich weiß, hat R. Fielding den Begriff geprägt, als er die Architektur und die Entscheidungen, die zu HTTP führten, beschrieb. In seiner These geht es mehr um die Architektur und die Cache-Fähigkeit von Ressourcen als um HTTP.

Wenn Sie sich wirklich dafür interessieren, was eine RESTful-Architektur ist und warum sie funktioniert, lesen Sie seine Dissertation ein paar Mal und lesen Sie die ganze Sache nicht nur Kapitel 5! Nächster Blick in warum DNS funktioniert . Informieren Sie sich über die hierarchische Organisation des DNS und wie Verweise funktionieren. Dann lesen Sie, wie DNS-Caching funktioniert. Schließlich lesen Sie die HTTP-Spezifikationen ( RFC2616 y RFC3040 ) und überlegen Sie, wie und warum die Zwischenspeicherung so funktioniert, wie sie funktioniert. Irgendwann macht es dann einfach Klick. Die letzte Offenbarung war für mich, als ich die Ähnlichkeit zwischen DNS und HTTP erkannte. Danach beginnt man zu verstehen, warum SOA und Message Passing Interfaces skalierbar sind.

Ich denke, dass der wichtigste Trick zum Verständnis der architektonischen Bedeutung und der Auswirkungen auf die Leistung einer RESTful- und Geteiltes Nichts Architekturen ist es, sich nicht mit den Details der Technologie und der Implementierung aufzuhalten. Konzentrieren Sie sich darauf, wem die Ressourcen gehören, wer für ihre Erstellung und Pflege verantwortlich ist usw. Denken Sie dann über die Darstellungen, Protokolle und Technologien nach.

Answer 4

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 y age bleibt unverändert):

PATCH /user/123
fname=Johnny

Zur Aktualisierung des Datensatzes (und folglich lname y age wird NULL sein):

PUT /user/123
fname=Johnny

Answer 5

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

Pflichtlektüre sind Repräsentative Zustandsübertragung (REST) y REST-APIs müssen hypertextgesteuert sein

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

Um RESTful zu sein, muss ein Dienst die Hypermedia als Motor des Anwendungsstatus. (HATEOAS) d.h. sie muss im RMM die Stufe 3 erreichen, den Artikel lesen für Einzelheiten oder die Folien des qcon-Vortrags .

Die HATEOAS-Bedingung ist ein Akronym für Hypermedia als Motor des Anwendungszustand. Dieses Prinzip ist das Hauptunterscheidungsmerkmal zwischen einer REST und den meisten anderen Formen von Client-Server System.

...

Ein Client einer RESTful-Anwendung muss nur eine einzige feste URL kennen, um darauf zu sie zuzugreifen. Alle zukünftigen Aktionen sollten dynamisch auffindbar sein von Hypermedia-Links, die in den Repräsentationen der Ressourcen, die die von dieser URL zurückgegeben werden. Standardisierte Medientypen werden auch von jedem Client verstanden werden Client verstanden werden, der eine RESTful API verwenden könnte. (Aus Wikipedia, der freien Enzyklopädie)

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

Annäherung an reines REST: HATEOAS lieben lernen ist eine gute Sammlung von Links.

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

REST und Versionierung diskutiert Erweiterbarkeit, Versionierung, Evolvierbarkeit, etc. durch Modifizierbarkeit