Was genau ist RESTful-Programmierung?

Was genau ist RESTful-Programmierung?

Ein Architekturstil namens REST (Representational State Transfer) befürwortet, dass Webanwendungen HTTP verwenden sollten, wie es ursprünglich vorgesehen war . Lookups sollten GETAnforderungen verwenden. PUT, POSTUnd DELETEAnfragen sollten verwendet werden für jeweils Mutation, Erstellung und Löschung .

REST-Befürworter tendieren dazu, URLs zu bevorzugen, wie z

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

Für die REST-Architektur sind diese "hübschen URLs" jedoch nicht erforderlich. Eine GET-Anfrage mit einem Parameter

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

ist genauso ruhig.

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

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

wäre nicht angebracht. GET-Anfragen sollten idempotent sein . Das heißt, das zweimalige Ausgeben einer Anfrage sollte sich nicht vom einmaligen Ausstellen unterscheiden. Das macht die Anfragen zwischenspeicherbar. Eine Anforderung zum Hinzufügen zum Warenkorb ist nicht idempotent. Wenn Sie sie zweimal ausgeben, werden zwei Kopien des Artikels in den Warenkorb gelegt. Eine POST-Anfrage ist in diesem Zusammenhang eindeutig angemessen. Daher benötigt auch eine RESTful-Webanwendung ihren Anteil an POST-Anforderungen.

Dies stammt aus dem hervorragenden Buch Core JavaServer Gesichter von David M. Geary.

REST ist das zugrunde liegende Architekturprinzip des Webs. Das Erstaunliche am Web ist die Tatsache, dass Clients (Browser) und Server auf komplexe Weise interagieren können, ohne dass der Client zuvor etwas über den Server und die darin gehosteten Ressourcen weiß. Die Hauptbeschränkung besteht darin, dass sowohl der Server als auch der Client sich auf die verwendeten Medien einigen müssen , bei denen es sich im Web um HTML handelt .

Für eine API, die den Prinzipien von REST entspricht, muss der Client nichts über die Struktur der API wissen. Der Server muss vielmehr alle Informationen bereitstellen, die der Client für die Interaktion mit dem Dienst benötigt. Ein Beispiel hierfür ist ein HTML-Formular : Der Server gibt den Speicherort der Ressource und die erforderlichen Felder an. Der Browser weiß nicht im Voraus, wo die Informationen übermittelt werden sollen, und er weiß nicht im Voraus, welche Informationen übermittelt werden sollen. Beide Arten von Informationen werden vollständig vom Server bereitgestellt. (Dieses Prinzip heißt HATEOAS : Hypermedia als Motor des Anwendungsstatus .)

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

Stellen wir uns zum Beispiel vor, wir haben eine Benutzerdatenbank, die von einem Webdienst verwaltet wird. Unser Service verwendet ein auf JSON basierendes benutzerdefiniertes Hypermedia, für das wir den Mimetyp zuweisen application/json+userdb(möglicherweise werden auch ein application/xml+userdbund application/whatever+userdb- viele Medientypen unterstützt). Der Client und der Server wurden beide so programmiert, dass sie dieses Format verstehen, aber sie wissen nichts voneinander. Wie Roy Fielding betont:

Eine REST-API sollte fast den gesamten beschreibenden Aufwand für die Definition der Medientypen verwenden, die zur Darstellung von Ressourcen und zur Steuerung des Anwendungsstatus verwendet werden, oder für die Definition erweiterter Beziehungsnamen und / oder hypertextfähiger Markierungen für vorhandene Standardmedientypen.

Eine Anforderung für die Basisressource /könnte Folgendes zurückgeben:

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 zu verwandten Ressourcen in Abschnitten finden können, die als "Links" bezeichnet werden. Dies wird als Hypermedia-Steuerelement bezeichnet . In diesem Fall können wir anhand eines solchen Abschnitts erkennen, dass wir eine Benutzerliste finden können, indem wir eine weitere Anfrage stellen 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"
        }
    ]
}

Wir können viel aus dieser Antwort sagen. Zum Beispiel wissen wir jetzt , wir einen neuen Benutzer durch erstellen POSTzu ing /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, DELETEetc.) , diese Ressourcen zu manipulieren, und dass das einzige Wissen , das wir auf der Client-Teil vermuten ist unsere Mediendefinition.

Weiterführende Literatur:

• Die vielen viel besseren Antworten auf dieser Seite.
• Wie ich meiner Frau REST erklärte .
• Wie ich meiner Frau REST erklärte .
• Martin Fowlers Gedanken
• Die PayPal-API verfügt über Hypermedia-Steuerelemente

(Diese Antwort wurde vielfach kritisiert, weil sie den Punkt verfehlt hatte. Zum größten Teil war dies eine faire Kritik. Was ich ursprünglich beschrieben habe, entsprach eher der Art und Weise, wie REST vor einigen Jahren normalerweise implementiert wurde, als ich es tat schrieb dies zuerst und nicht seine wahre Bedeutung. Ich habe die Antwort überarbeitet, um die wahre Bedeutung besser darzustellen.)

Bei der RESTful-Programmierung geht es um:

• Ressourcen, die durch eine persistente Kennung identifiziert werden: URIs sind heutzutage die allgegenwärtige Wahl der Kennung
• Ressourcen werden mit einem gemeinsamen Satz von Verben manipuliert: HTTP - Methoden sind die häufigsten gesehen Fall - der ehrwürdige Create, Retrieve, Update, Deletewird POST, GET, PUT, und DELETE. REST ist jedoch nicht auf HTTP beschränkt, sondern derzeit nur der am häufigsten verwendete Transport.
• Die tatsächliche Darstellung, die für eine Ressource abgerufen wird, hängt von der Anforderung und nicht von der Kennung ab: Verwenden Sie Accept-Header, um zu steuern, ob Sie XML, HTTP oder sogar ein Java-Objekt möchten, das die Ressource darstellt
• Beibehalten des Zustands im Objekt und Darstellen des Zustands in der Darstellung
• Darstellung der Beziehungen zwischen Ressourcen in der Darstellung der Ressource: Die Verknüpfungen zwischen Objekten werden direkt in die Darstellung eingebettet
• Ressourcendarstellungen beschreiben, wie die Darstellung verwendet werden kann und unter welchen Umständen sie auf konsistente Weise verworfen / erneut abgerufen werden sollte: Verwendung von HTTP-Cache-Control-Headern

Der letzte ist wahrscheinlich der wichtigste in Bezug auf die Konsequenzen und die allgemeine Wirksamkeit von REST. Insgesamt scheinen sich die meisten RESTful-Diskussionen auf HTTP und dessen Verwendung über einen Browser zu konzentrieren und was nicht. Ich verstehe, dass R. Fielding den Begriff geprägt hat, als er die Architektur und Entscheidungen beschrieb, die zu HTTP führen. In seiner Arbeit geht es mehr um die Architektur und die Cache-Fähigkeit von Ressourcen als um HTTP.

Wenn Sie wirklich daran interessiert sind, was eine RESTful-Architektur ist und warum sie funktioniert, lesen Sie seine These ein paar Mal und lesen Sie das Ganze nicht nur in Kapitel 5! Schauen Sie sich als nächstes an, warum DNS funktioniert . Lesen Sie mehr über die hierarchische Organisation von DNS und die Funktionsweise von Verweisen. Lesen Sie dann, wie das DNS-Caching funktioniert. Lesen Sie abschließend die HTTP-Spezifikationen (insbesondere RFC2616 und RFC3040 ) und überlegen Sie, wie und warum das Caching so funktioniert, wie es funktioniert. Schließlich wird es nur klicken. Die letzte Offenbarung für mich war, als ich die Ähnlichkeit zwischen DNS und HTTP sah. Danach beginnt das Verständnis, warum SOA- und Message Passing-Schnittstellen skalierbar sind, zu klicken.

Ich denke, dass der wichtigste Trick, um die architektonische Bedeutung und die Auswirkungen auf die Leistung einer RESTful- und Shared Nothing- Architektur zu verstehen , darin besteht, nicht an den Details der Technologie und Implementierung zu hängen. Konzentrieren Sie sich darauf, wem Ressourcen gehören, wer für deren Erstellung / Wartung verantwortlich ist usw. Denken Sie dann über die Darstellungen, Protokolle und Technologien nach.

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>

So ändern Sie den Datensatz ( lnameund agebleiben unverändert):

PATCH /user/123
fname=Johnny

So aktualisieren Sie den Datensatz (und folglich lnameund agewird NULL):

PUT /user/123
fname=Johnny

Ein großartiges Buch über REST ist REST in der Praxis .

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

In Martin Fowlers Artikel über das Richardson Maturity Model (RMM) finden Sie eine Erklärung, was ein RESTful-Service ist.

Um RESTful zu sein, muss ein Service die Hypermedia als Engine of Application State erfüllen . (HATEOAS) , das heißt, es muss Level 3 im RMM erreichen, den Artikel für Details oder die Folien aus dem qcon-Vortrag lesen .

Die HATEOAS-Einschränkung ist eine Abkürzung für Hypermedia als Engine of Application State. Dieses Prinzip ist das Hauptunterscheidungsmerkmal zwischen einem REST und den meisten anderen Formen von Client-Server-Systemen.

...

Ein Client einer RESTful-Anwendung muss nur eine einzige feste URL kennen, um darauf zugreifen zu können. Alle zukünftigen Aktionen sollten dynamisch über Hypermedia-Links erkennbar sein, die in den Darstellungen der Ressourcen enthalten sind, die von dieser URL zurückgegeben werden. Es wird auch erwartet, dass standardisierte Medientypen von jedem Client verstanden werden, der möglicherweise eine RESTful-API verwendet. (Aus Wikipedia, der freien Enzyklopädie)

Der REST-Lackmustest 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.

In REST versus SOAP für die Public Cloud werden die aktuellen REST-Nutzungsniveaus erläutert.

In REST und Versionierung werden Erweiterbarkeit, Versionierung, Evolvabilität usw. durch Modifizierbarkeit erläutert

Was ist REST?

REST steht für Representational State Transfer. (Manchmal wird es als "ReST" geschrieben.) Es basiert auf einem zustandslosen, zwischenspeicherbaren Client-Server-Kommunikationsprotokoll - und in praktisch allen Fällen wird das HTTP-Protokoll verwendet.

REST ist ein Architekturstil zum Entwerfen von Netzwerkanwendungen. Die Idee ist, dass anstelle komplexer Mechanismen wie CORBA, RPC oder SOAP für die Verbindung zwischen Computern einfaches HTTP verwendet wird, um Anrufe zwischen Computern zu tätigen.

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

REST ist eine einfache Alternative zu Mechanismen wie RPC (Remote Procedure Calls) und Web Services (SOAP, WSDL, et al.). Später werden wir sehen, wie viel einfacher REST ist.

Obwohl REST einfach ist, ist es voll funktionsfähig. Grundsätzlich können Sie in Web Services nichts tun, was mit einer RESTful-Architektur nicht möglich ist. REST ist kein "Standard". Es wird zum Beispiel niemals eine W3C-Empfehlung für REST geben. Und obwohl es REST-Programmierframeworks gibt, ist die Arbeit mit REST so einfach, dass Sie häufig mit Standardbibliotheksfunktionen in Sprachen wie Perl, Java oder C # "Ihre eigenen rollen" können.

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

http://rest.elkstein.org/

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

Anstatt eine bestimmte URL zum Löschen einer Methode (z. B. /user/123/delete) zu verwenden, würden Sie eine DELETE-Anforderung an die /user/[id]URL senden , einen Benutzer bearbeiten und Informationen zu einem Benutzer abrufen, an den Sie eine GET-Anforderung senden/user/[id]

Zum Beispiel stattdessen eine Reihe von URLs, die wie folgt aussehen könnten:

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

Es ist die Programmierung, bei der die Architektur Ihres Systems dem REST-Stil entspricht , den Roy Fielding in seiner Dissertation dargelegt hat . Da dies der Architekturstil ist, der das Web beschreibt (mehr oder weniger), interessieren sich viele Menschen dafür.

Bonusantwort: Nein. Wenn Sie nicht als Akademiker Softwarearchitektur studieren oder Webdienste entwerfen, gibt es wirklich keinen Grund, den Begriff gehört zu haben.

Ich würde sagen, bei der RESTful-Programmierung geht es darum, Systeme (API) zu erstellen, 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 zum größten Teil beantworten würde:

Lerne REST: Ein Tutorial

REST ist ein Architekturstil zum Entwerfen von Netzwerkanwendungen. Die Idee ist, dass anstelle komplexer Mechanismen wie CORBA, RPC oder SOAP für die Verbindung zwischen Computern einfaches HTTP verwendet wird, um Anrufe zwischen Computern zu tätigen.

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

RESTful-Anwendungen verwenden HTTP-Anforderungen, um Daten zu veröffentlichen (erstellen und / oder aktualisieren), Daten zu lesen (z. B. Abfragen durchzuführen) und Daten zu löschen. Daher verwendet REST HTTP für alle vier CRUD-Vorgänge (Erstellen / Lesen / Aktualisieren / Löschen).

Ich denke nicht, dass Sie sich dumm fühlen sollten, wenn Sie nicht von REST außerhalb von Stack Overflow hören ..., ich wäre in der gleichen Situation!; Antworten auf diese andere SO-Frage, warum REST jetzt groß wird, könnten einige Gefühle lindern.

Ich entschuldige mich, wenn ich die Frage nicht direkt beantworte, aber es ist einfacher, dies alles anhand detaillierterer Beispiele zu verstehen. Fielding ist aufgrund der gesamten Abstraktion und Terminologie nicht leicht zu verstehen.

Hier gibt es ein ziemlich gutes Beispiel:

REST und Hypertext erklären: Spam-E, der Spam-Reinigungsroboter

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

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 jedoch nicht sicher, ob er Recht hat, da dieser / user / 123 ein URI ist, der auf eine Ressource verweist, und mir nicht klar ist, dass er nicht restriktiv ist, nur weil der Client davon "out-of-band" weiß.

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

Was ist REST?

REST in offiziellen Worten, REST ist ein Architekturstil, der auf bestimmten Prinzipien basiert und die aktuellen „Web“ -Begründungen verwendet. Es gibt 5 grundlegende Grundlagen des Webs, die zur Erstellung von REST-Services genutzt werden.

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

Ich sehe eine Reihe von Antworten, die besagen, dass es RESTful ist, alles über Benutzer 123 in die Ressource "/ user / 123" zu setzen.

Roy Fielding, der den Begriff geprägt hat, sagt, dass REST-APIs hypertextgesteuert sein müssen . Insbesondere "Eine REST-API darf keine festen Ressourcennamen oder -hierarchien definieren".

Wenn Ihr "/ user / 123" -Pfad auf dem Client fest codiert ist, ist er nicht wirklich RESTful. Eine gute Verwendung von HTTP, vielleicht, vielleicht auch nicht. Aber nicht RESTful. Es muss aus Hypertext kommen.

Die Antwort ist sehr einfach, es gibt eine Dissertation von Roy Fielding.] 1 In dieser Dissertation definiert er die REST-Prinzipien. Wenn eine Anwendung alle diese Prinzipien erfüllt, handelt es sich um eine REST-Anwendung.

Der Begriff RESTful wurde erstellt, weil ppl das Wort REST erschöpft hat, indem die Nicht-REST-Anwendung als REST bezeichnet wurde. Danach war auch der Begriff RESTful erschöpft. Heutzutage sprechen wir über Web-APIs und Hypermedia-APIs , da die meisten sogenannten REST-Anwendungen den HATEOAS-Teil der einheitlichen Schnittstellenbeschränkung nicht erfüllten.

Die REST-Einschränkungen sind folgende:

1. Client-Server-Architektur

   So funktioniert es beispielsweise nicht mit PUB / SUB-Sockets, sondern basiert auf REQ / REP.

2. staatenlose Kommunikation

   Der Server behält also nicht den Status der Clients bei. Dies bedeutet, dass Sie keinen Server als Nebensitzungsspeicher verwenden können und jede Anforderung authentifizieren müssen. Ihre Clients senden möglicherweise grundlegende Authentifizierungsheader über eine verschlüsselte Verbindung. (Bei großen Anwendungen ist es schwierig, viele Sitzungen aufrechtzuerhalten.)

3. Verwendung des Cache, wenn Sie können

   Sie müssen also nicht immer wieder dieselben Anfragen bearbeiten.

4. einheitliche Schnittstelle als gemeinsamer Vertrag zwischen Client und Server

   Der Vertrag zwischen dem Client und dem Server wird vom Server nicht gepflegt. Mit anderen Worten, der Client muss von der Implementierung des Dienstes entkoppelt sein. Sie können diesen Status erreichen, indem Sie Standardlösungen wie den IRI (URI) -Standard zur Identifizierung von Ressourcen, den HTTP-Standard zum Austausch von Nachrichten, Standard-MIME-Typen zur Beschreibung des Körperserialisierungsformats, Metadaten (möglicherweise RDF-Vokabeln, Mikroformate usw.) verwenden Beschreiben Sie die Semantik verschiedener Teile des Nachrichtentexts. Um die IRI-Struktur vom Client zu entkoppeln, müssen Sie Hyperlinks in Hypermedia-Formaten wie (HTML, JSON-LD, HAL usw.) an die Clients senden. So kann ein Client die den Hyperlinks zugewiesenen Metadaten (möglicherweise Verknüpfungsbeziehungen, RDF-Vokabeln) verwenden, um die Zustandsmaschine der Anwendung durch die richtigen Zustandsübergänge zu navigieren, um ihr aktuelles Ziel zu erreichen.

   Wenn ein Kunde beispielsweise eine Bestellung an einen Webshop senden möchte, muss er die Hyperlinks in den vom Webshop gesendeten Antworten überprüfen. Durch Überprüfen der Links wird einer gefunden, der mit http://schema.org/OrderAction beschrieben wurde . Der Client kennt das Vokabular von schema.org und versteht daher, dass er durch Aktivieren dieses Hyperlinks die Bestellung sendet. Es aktiviert also den Hyperlink und sendet eine POST https://example.com/api/v1/orderNachricht mit dem richtigen Text. Danach verarbeitet der Dienst die Nachricht und antwortet mit dem Ergebnis mit dem richtigen HTTP-Status-Header, beispielsweise 201 - createddurch Erfolg. Zum Kommentieren von Nachrichten mit detaillierten Metadaten ist die Standardlösung die Verwendung eines RDF-Formats, z. B. JSON-LD mit einem REST-Vokabular, z. B. Hydra und domänenspezifische Vokabeln wieschema.org oder ein anderes Vokabular für verknüpfte Daten und gegebenenfalls ein benutzerdefiniertes anwendungsspezifisches Vokabular. Das ist nicht einfach, deshalb verwenden die meisten Leute HAL und andere einfache Formate, die normalerweise nur ein REST-Vokabular bieten, aber keine Unterstützung für verknüpfte Daten.

5. Erstellen Sie ein Schichtsystem, um die Skalierbarkeit zu erhöhen

   Das REST-System besteht aus hierarchischen Schichten. Jede Schicht enthält Komponenten, die die Dienste von Komponenten nutzen, die sich in der nächsten Schicht darunter befinden. So können Sie mühelos neue Ebenen und Komponenten hinzufügen.

   Beispielsweise gibt es eine Client-Schicht, die die Clients enthält, und darunter eine Service-Schicht, die einen einzelnen Service enthält. Jetzt können Sie einen clientseitigen Cache zwischen ihnen hinzufügen. Danach können Sie eine weitere Dienstinstanz und einen Load Balancer usw. hinzufügen. Der Clientcode und der Dienstcode werden nicht geändert.

6. Code on Demand zur Erweiterung der Client-Funktionalität

   Diese Einschränkung ist optional. Sie können beispielsweise einen Parser für einen bestimmten Medientyp an den Client senden usw. Um dies zu tun, benötigen Sie möglicherweise ein Standard-Plugin-Loader-System im Client, oder Ihr Client wird an die Plugin-Loader-Lösung gekoppelt .

REST-Einschränkungen führen zu einem hoch skalierbaren System, in dem die Clients von den Implementierungen der Services entkoppelt sind. So können die Clients wiederverwendbar sein, allgemein wie die Browser im Web. Die Clients und die Services teilen dieselben Standards und Vokabeln, sodass sie sich gegenseitig verstehen können, obwohl der Client die Implementierungsdetails des Service nicht kennt. Dies ermöglicht die Erstellung automatisierter Clients, die REST-Services finden und nutzen können, um ihre Ziele zu erreichen. Langfristig können diese Kunden miteinander kommunizieren und sich gegenseitig Aufgaben anvertrauen, so wie es Menschen tun. Wenn wir solchen Clients Lernmuster hinzufügen, ist das Ergebnis eine oder mehrere KI, die das Maschinennetz anstelle eines einzelnen Serverparks verwenden. Also am Ende der Traum von Berners Lee: Das Semantic Web und die künstliche Intelligenz werden Realität. So werden wir 2030 vom Skynet beendet. Bis dann ... ;-)

Bei der RESTful- API-Programmierung (Representational State Transfer) werden Webanwendungen in einer beliebigen Programmiersprache geschrieben, indem 5 grundlegende Prinzipien des Software- Architekturstils befolgt werden:

1. Ressource (Daten, Informationen).
2. Eindeutige globale Kennung (alle Ressourcen sind durch URI eindeutig gekennzeichnet ).
3. Einheitliche Schnittstelle - Verwenden Sie eine einfache und Standardschnittstelle (HTTP).
4. Repräsentation - Die gesamte Kommunikation erfolgt durch Repräsentation (z. B. XML / JSON ).
5. Statuslos (jede Anforderung erfolgt vollständig isoliert, es ist einfacher, sie zwischenzuspeichern und den Lastenausgleich durchzuführen),

Mit anderen Worten, Sie schreiben einfache Punkt-zu-Punkt-Netzwerkanwendungen über HTTP, die Verben wie GET, POST, PUT oder DELETE verwenden, indem Sie eine RESTful-Architektur implementieren, die eine Standardisierung der Schnittstelle vorschlägt, die jede „Ressource“ verfügbar macht. Es ist nichts anderes, als die aktuellen Funktionen des Webs auf einfache und effektive Weise zu nutzen (sehr erfolgreiche, bewährte und verteilte Architektur). Es ist eine Alternative zu komplexeren Mechanismen wie SOAP , CORBA und RPC .

RESTful-Programmierung entspricht dem Design der Webarchitektur und ermöglicht bei ordnungsgemäßer Implementierung die volle Nutzung der skalierbaren Webinfrastruktur.

Wenn ich die ursprüngliche Dissertation über REST auf nur 3 kurze Sätze reduzieren müsste, würde das Folgende meiner Meinung nach das Wesentliche erfassen:

1. Ressourcen werden über URLs angefordert.
2. Protokolle beschränken sich auf das, was Sie mithilfe von URLs kommunizieren können.
3. Metadaten werden als Name-Wert-Paare übergeben (Post-Daten und Abfragezeichenfolgenparameter).

Danach kann es leicht zu Debatten über Anpassungen, Codierungskonventionen und Best Practices kommen.

Interessanterweise werden HTTP-POST-, GET-, DELETE- oder PUT-Operationen in der Dissertation nicht erwähnt. Das muss jemandes spätere Interpretation einer "Best Practice" für eine "einheitliche Schnittstelle" sein.

Wenn es um Webdienste geht, scheint es eine Möglichkeit zu geben, WSDL- und SOAP-basierte Architekturen zu unterscheiden, die der Benutzeroberfläche einen erheblichen Overhead und möglicherweise viel unnötige Komplexität hinzufügen. Sie erfordern außerdem zusätzliche Frameworks und Entwicklertools, um implementiert zu werden. Ich bin mir nicht sicher, ob REST der beste Begriff ist, um zwischen Common-Sense-Schnittstellen und überentwickelten Schnittstellen wie WSDL und SOAP zu unterscheiden. Aber wir brauchen etwas.

REST ist ein Architekturmuster und ein Schreibstil für verteilte Anwendungen. Es ist kein Programmierstil im engeren Sinne.

Die Aussage, dass Sie den REST-Stil verwenden, ähnelt der Aussage, dass Sie ein Haus in einem bestimmten Stil gebaut haben: zum Beispiel Tudor oder Victorian. Sowohl REST als Softwarestil als auch Tudor oder Victorian als Heimstil können durch die Eigenschaften und Einschränkungen definiert werden, aus denen sie bestehen. Beispielsweise muss REST über eine Client-Server-Trennung verfügen, bei der sich Nachrichten selbst beschreiben. Häuser im Tudor-Stil haben überlappende Giebel und Dächer, die steil mit nach vorne gerichteten Giebeln geneigt sind. Sie können Roys Dissertation lesen, um mehr über die Einschränkungen und Eigenschaften von REST zu erfahren.

REST hatte es im Gegensatz zu Wohnstilen schwer, konsequent und praktisch angewendet zu werden. Dies kann beabsichtigt gewesen sein. Überlassen Sie die eigentliche Implementierung dem Designer. Sie können also tun, was Sie wollen, solange Sie die in der von Ihnen erstellten Dissertation festgelegten Einschränkungen erfüllen.

Bonus:

Das gesamte Web basiert auf REST (oder REST basierte auf dem Web). Daher möchten Sie als Webentwickler vielleicht wissen, dass es nicht notwendig ist, gute Web-Apps zu schreiben.

Hier ist mein Grundriss von REST. Ich habe versucht, das Denken hinter jeder der Komponenten in einer RESTful-Architektur zu demonstrieren, damit das Verständnis des Konzepts intuitiver ist. Hoffentlich hilft dies REST für einige Leute zu entmystifizieren!

REST (Representational State Transfer) ist eine Entwurfsarchitektur, die beschreibt, wie vernetzte Ressourcen (dh Knoten, die Informationen gemeinsam nutzen) entworfen und adressiert werden. Im Allgemeinen ermöglicht eine RESTful-Architektur, dass der Client (der anfordernde Computer) und der Server (der antwortende Computer) das Lesen, Schreiben und Aktualisieren von Daten anfordern können, ohne dass der Client wissen muss, wie der Server funktioniert und der Server übergeben kann es zurück, ohne etwas über den Kunden wissen zu müssen. Okay, cool ... aber wie machen wir das in der Praxis?

• Die offensichtlichste Anforderung ist, dass es eine universelle Sprache geben muss, damit der Server dem Client mitteilen kann, was er mit der Anforderung zu tun versucht, und dass der Server antworten soll.

• Um jedoch eine bestimmte Ressource zu finden und dem Kunden dann mitzuteilen, wo sich diese Ressource befindet, muss es eine universelle Möglichkeit geben, auf Ressourcen zu verweisen. Hier kommen Universal Resource Identifiers (URIs) ins Spiel. Sie sind im Grunde eindeutige Adressen, um die Ressourcen zu finden.

Aber die REST-Architektur endet nicht dort! Während das oben Genannte die Grundanforderungen unserer Anforderungen erfüllt, möchten wir auch eine Architektur haben, die Datenverkehr mit hohem Datenvolumen unterstützt, da jeder Server normalerweise Antworten von mehreren Clients verarbeitet. Daher möchten wir den Server nicht überfordern, indem er sich Informationen über frühere Anforderungen merkt.

• Daher legen wir die Einschränkung fest, dass jedes Anforderungs-Antwort-Paar zwischen dem Client und dem Server unabhängig ist, was bedeutet, dass sich der Server nichts über frühere Anforderungen (frühere Zustände der Client-Server-Interaktion) merken muss, um auf eine neue zu antworten Anfrage. Dies bedeutet, dass wir möchten, dass unsere Interaktionen zustandslos sind.

• Um die Belastung unseres Servers durch das Wiederherstellen von Berechnungen, die bereits kürzlich für einen bestimmten Client durchgeführt wurden, weiter zu verringern, ermöglicht REST auch das Caching. Grundsätzlich bedeutet Caching, einen Schnappschuss der ersten Antwort zu erstellen, die dem Client bereitgestellt wird. Wenn der Client dieselbe Anforderung erneut stellt, kann der Server dem Client den Snapshot bereitstellen, anstatt alle Berechnungen zu wiederholen, die zum Erstellen der ersten Antwort erforderlich waren. Da es sich jedoch um einen Snapshot handelt, legt der Server eine Ablaufzeit im Voraus fest, wenn der Snapshot nicht abgelaufen ist - und die Antwort wurde seit dem ersten Cache aktualisiert (dh die Anforderung würde eine andere Antwort als die zwischengespeicherte Antwort geben). Der Client sieht die Aktualisierungen erst, wenn der Cache abläuft (oder der Cache geleert wird) und die Antwort erneut von Grund auf neu gerendert wird.

• Das Letzte, was Sie hier häufig über RESTful-Architekturen erfahren, ist, dass sie überlagert sind. Wir haben diese Anforderung bereits implizit in unserer Diskussion über die Interaktion zwischen Client und Server erörtert. Grundsätzlich bedeutet dies, dass jede Schicht in unserem System nur mit benachbarten Schichten interagiert. In unserer Diskussion interagiert die Client-Schicht mit unserer Server-Schicht (und umgekehrt). Es kann jedoch auch andere Server-Schichten geben, die dem Primärserver helfen, eine Anforderung zu verarbeiten, mit der der Client nicht direkt kommuniziert. Vielmehr leitet der Server die Anforderung nach Bedarf weiter.

Wenn Ihnen das alles bekannt vorkommt, dann großartig. Das Hypertext Transfer Protocol (HTTP), das das Kommunikationsprotokoll über das World Wide Web definiert, ist eine Implementierung des abstrakten Begriffs der RESTful-Architektur (oder eine Instanz der REST-Klasse, wenn Sie ein OOP-Fan wie ich sind). Bei dieser Implementierung von REST interagieren Client und Server über GET, POST, PUT, DELETE usw., die Teil der universellen Sprache sind und auf die mithilfe von URLs verwiesen werden kann.

Ich denke, der Punkt der Ruhe ist die Trennung der Statefulness in eine höhere Schicht, während das Internet (Protokoll) als zustandslose Transportschicht genutzt wird . Die meisten anderen Ansätze vermischen die Dinge.

Es war der beste praktische Ansatz, um die grundlegenden Änderungen der Programmierung im Internet-Zeitalter zu bewältigen. In Bezug auf die grundlegenden Änderungen hat Erik Meijer hier eine Diskussion zu sehen: http://www.infoq.com/interviews/erik-meijer-programming-language-design-effects-purity#view_93197 . Er fasst es als die fünf Effekte zusammen und präsentiert eine Lösung, indem er die Lösung in eine Programmiersprache entwirft. Die Lösung könnte unabhängig von der Sprache auch auf Plattform- oder Systemebene erreicht werden. Das Erholsame könnte als eine der Lösungen angesehen werden, die in der gegenwärtigen Praxis sehr erfolgreich waren.

Mit einem erholsamen Stil können Sie den Status der Anwendung über ein unzuverlässiges Internet abrufen und bearbeiten. Wenn die aktuelle Operation fehlschlägt, um den korrekten und aktuellen Status zu erhalten, benötigt sie das Prinzip der Nullvalidierung, damit die Anwendung fortgesetzt werden kann. Wenn der Status nicht manipuliert werden kann, werden normalerweise mehrere Bestätigungsstufen verwendet, um die Richtigkeit zu gewährleisten. In diesem Sinne ist Rest selbst keine vollständige Lösung, sondern benötigt die Funktionen in einem anderen Teil des Webanwendungsstapels, um seine Arbeit zu unterstützen.

Unter diesem Gesichtspunkt ist der Reststil nicht wirklich an das Internet oder die Webanwendung gebunden. Es ist eine grundlegende Lösung für viele Programmiersituationen. Es ist auch nicht einfach, es macht nur die Oberfläche wirklich einfach und kommt mit anderen Technologien erstaunlich gut zurecht.

Nur mein 2c.

Bearbeiten: Zwei weitere wichtige Aspekte:

• Staatenlosigkeit ist irreführend. Es geht um die erholsame API, nicht um die Anwendung oder das System. Das System muss zustandsbehaftet sein. Beim Restful Design geht es darum, ein Stateful-System zu entwerfen, das auf einer zustandslosen API basiert. Einige Zitate aus einer anderen Qualitätssicherung :

  • REST verarbeitet Ressourcendarstellungen, die jeweils durch eine URL gekennzeichnet sind. Dies sind normalerweise keine Datenobjekte, sondern komplexe Objektabstraktionen .
  • REST steht für "Representational State Transfer", dh es geht darum, den Status einer Ressource in einem System zu kommunizieren und zu ändern .

• Idempotenz : Ein oft übersehener Teil von REST ist die Idempotenz der meisten Verben. Dies führt zu robusten Systemen und einer geringeren gegenseitigen Abhängigkeit der genauen Interpretationen der Semantik .

Dies ist eine erstaunlich lange "Diskussion" und doch, gelinde gesagt, ziemlich verwirrend.

IMO:

1) Es gibt keine erholsame Programmierung ohne einen großen Joint und viel Bier :)

2) Representational State Transfer (REST) ​​ist ein Architekturstil, der in der Dissertation von Roy Fielding festgelegt wurde . Es gibt eine Reihe von Einschränkungen. Wenn Ihr Service / Kunde diese respektiert, ist es RESTful. Das ist es.

Sie können die Einschränkungen (erheblich) zusammenfassen für:

• staatenlose Kommunikation
• HTTP-Spezifikationen beachten (wenn HTTP verwendet wird)
• kommuniziert klar die übertragenen Inhaltsformate
• Verwenden Sie Hypermedia als Engine für den Anwendungsstatus

Es gibt noch einen sehr guten Beitrag, der die Dinge gut erklärt.

Viele Antworten kopieren / fügen gültige Informationen ein, mischen sie und sorgen für Verwirrung. Die Leute reden hier über Ebenen, über RESTFul-URIs (so etwas gibt es nicht!), Wenden HTTP-Methoden an GET, POST, PUT ... Bei REST geht es nicht darum oder nicht nur darum.

Zum Beispiel Links - es ist schön, eine schön aussehende API zu haben, aber am Ende kümmert sich der Client / Server nicht wirklich um die Links, die Sie erhalten / senden. Es ist der Inhalt, der zählt.

Am Ende sollte jeder RESTful-Client in der Lage sein, einen beliebigen RESTful-Service zu nutzen, solange das Inhaltsformat bekannt ist.

Alte Frage, neue Art zu antworten. Es gibt viele Missverständnisse über dieses Konzept. Ich versuche mich immer zu erinnern:

1. Strukturierte URLs und HTTP-Methoden / Verben sind nicht die Definition für eine erholsame Programmierung.
2. JSON ist keine erholsame Programmierung
3. RESTful-Programmierung ist nicht für APIs

Ich definiere erholsame Programmierung als

Eine Anwendung ist erholsam, wenn sie Ressourcen (die Kombination aus Steuerelementen für Daten und Statusübergänge) in einem Medientyp bereitstellt, den der Client versteht

Um ein erholsamer Programmierer zu sein, müssen Sie versuchen, Anwendungen zu erstellen, mit denen Schauspieler Dinge tun können. Nicht nur die Datenbank verfügbar machen.

Zustandsübergangskontrollen sind nur dann sinnvoll, wenn sich Client und Server auf eine Medientypdarstellung der Ressource einigen. Andernfalls können Sie nicht wissen, was ein Steuerelement ist und was nicht und wie ein Steuerelement ausgeführt wird. Wenn Browser keine <form>Tags in HTML kannten, müssen Sie in Ihrem Browser nichts an den Übergangsstatus senden.

Ich möchte mich nicht selbst fördern, aber ich werde diese Ideen in meinem Vortrag http://techblog.bodybuilding.com/2016/01/video-what-is-restful-200.html ausführlich erläutern .

Ein Auszug aus meinem Vortrag handelt von dem oft erwähnten Richardson-Reifegradmodell. Ich glaube nicht an die Levels, Sie sind entweder RESTful (Level 3) oder Sie sind es nicht, aber ich möchte darauf hinweisen, was jedes Level ist tut für Sie auf dem Weg zu RESTful

REST definiert 6 architektonische Einschränkungen, die jeden Webdienst zu einer echten RESTful-API machen .

1. Einheitliche Schnittstelle
2. Kundenserver
3. Staatenlos
4. Cacheable
5. Schichtsystem
6. Code auf Anfrage (optional)

https://restfulapi.net/rest-architectural-constraints/

REST === Die HTTP-Analogie ist erst dann korrekt, wenn Sie nicht betonen, dass sie "MUSS" HATEOAS- gesteuert sein muss.

Roy selbst hat es hier geklärt .

Eine REST-API sollte ohne Vorkenntnisse über den ursprünglichen URI (Lesezeichen) und den Satz standardisierter Medientypen hinaus eingegeben werden, die für die beabsichtigte Zielgruppe geeignet sind (dh von jedem Client, der die API möglicherweise verwendet, verstanden werden). Ab diesem Zeitpunkt müssen alle Anwendungsstatusübergänge durch die Clientauswahl von vom Server bereitgestellten Auswahlmöglichkeiten gesteuert werden, die in den empfangenen Darstellungen vorhanden sind oder durch die Manipulation dieser Darstellungen durch den Benutzer impliziert werden. Die Übergänge können durch das Wissen des Kunden über Medientypen und Ressourcenkommunikationsmechanismen bestimmt (oder begrenzt) werden, die beide im laufenden Betrieb verbessert werden können (z. B. Code-on-Demand).

[Ein Fehler hier impliziert, dass Out-of-Band-Informationen die Interaktion anstelle von Hypertext steuern.]

REST ist ein Architekturstil, der auf Webstandards und dem im Jahr 2000 eingeführten HTTP-Protokoll basiert.

In einer REST-basierten Architektur ist alles eine Ressource (Benutzer, Bestellungen, Kommentare). Der Zugriff auf eine Ressource erfolgt über eine gemeinsame Schnittstelle, die auf den HTTP-Standardmethoden (GET, PUT, PATCH, DELETE usw.) basiert.

In einer REST-basierten Architektur verfügen Sie über einen REST-Server, der den Zugriff auf die Ressourcen ermöglicht. Ein REST-Client kann auf die REST-Ressourcen zugreifen und diese ändern.

Jede Ressource sollte die allgemeinen HTTP-Vorgänge unterstützen. Ressourcen werden durch globale IDs (normalerweise URIs) identifiziert.

REST ermöglicht, dass Ressourcen unterschiedliche Darstellungen haben, z. B. Text, XML, JSON usw. Der REST-Client kann über das HTTP-Protokoll eine bestimmte Darstellung anfordern (Inhaltsverhandlung).

HTTP-Methoden:

Die Methoden PUT, GET, POST und DELETE werden normalerweise in REST-basierten Architekturen verwendet. Die folgende Tabelle enthält eine Erläuterung dieser Vorgänge.

• GET definiert einen Lesezugriff auf die Ressource ohne Nebenwirkungen. Die Ressource wird niemals über eine GET-Anfrage geändert, z. B. hat die Anfrage keine Nebenwirkungen (idempotent).
• PUT erstellt eine neue Ressource. Es muss auch idempotent sein.
• DELETE entfernt die Ressourcen. Die Operationen sind idempotent. Sie können wiederholt werden, ohne zu unterschiedlichen Ergebnissen zu führen.
• POST aktualisiert eine vorhandene Ressource oder erstellt eine neue Ressource.

REST steht für Representational State Transfer .

Es basiert auf einem zustandslosen, zwischenspeicherbaren Client-Server-Kommunikationsprotokoll - und in praktisch allen Fällen wird das HTTP-Protokoll verwendet.

REST wird häufig in mobilen Anwendungen, Websites für soziale Netzwerke, Mashup-Tools und automatisierten Geschäftsprozessen verwendet. Der REST-Stil betont, dass die Interaktion zwischen Clients und Services durch eine begrenzte Anzahl von Operationen (Verben) verbessert wird. Flexibilität wird durch die Zuweisung von Ressourcen (Substantiven) zu ihren eigenen eindeutigen universellen Ressourcenindikatoren (URIs) gewährleistet.

Einführung über Rest

Sprechen ist mehr als nur Informationsaustausch . Ein Protokoll ist eigentlich so konzipiert, dass kein Sprechen stattfinden muss. Jede Partei weiß, was ihre jeweilige Aufgabe ist, da sie im Protokoll angegeben ist. Protokolle ermöglichen einen reinen Informationsaustausch auf Kosten von Änderungen der möglichen Aktionen. Durch das Sprechen hingegen kann eine Partei fragen, welche weiteren Maßnahmen von der anderen Partei ergriffen werden können. Sie können sogar zweimal dieselbe Frage stellen und zwei unterschiedliche Antworten erhalten, da sich der Zustand der anderen Partei in der Zwischenzeit möglicherweise geändert hat. Sprechen ist RESTful Architektur . Fieldings These spezifiziert die Architektur, der man folgen müsste, wenn man Maschinen erlauben möchte, miteinander zu reden und nicht nurkommunizieren .

Es gibt keinen Begriff wie "RESTful Programming" an sich. Es wäre besser als RESTful-Paradigma oder noch besser als RESTful-Architektur zu bezeichnen. Es ist keine Programmiersprache. Es ist ein Paradigma.

Aus Wikipedia :

Beim Computing ist der REST (Representational State Transfer) ein Architekturstil, der für die Webentwicklung verwendet wird.

Der Rest der Ruhe ist, dass, wenn wir uns darauf einigen, eine gemeinsame Sprache für grundlegende Operationen (die http-Verben) zu verwenden, die Infrastruktur so konfiguriert werden kann, dass sie verstanden und richtig optimiert wird, indem beispielsweise Caching-Header verwendet werden, um das Caching überhaupt zu implementieren Ebenen.

Bei einem ordnungsgemäß implementierten Restful GET-Vorgang sollte es keine Rolle spielen, ob die Informationen aus der Datenbank Ihres Servers, dem Memcache Ihres Servers, einem CDN, dem Cache eines Proxys, dem Cache Ihres Browsers oder dem lokalen Speicher Ihres Browsers stammen. Die schnellste, am leichtesten verfügbare, aktuelle Quelle kann verwendet werden.

Wenn Sie sagen, dass Rest nur eine syntaktische Änderung von der Verwendung von GET-Anforderungen mit einem Aktionsparameter zur Verwendung der verfügbaren http-Verben ist, sieht es so aus, als hätte es keine Vorteile und ist rein kosmetisch. Es geht darum, eine Sprache zu verwenden, die von jedem Teil der Kette verstanden und optimiert werden kann. Wenn Ihre GET-Operation eine Aktion mit Nebenwirkungen hat, müssen Sie das gesamte HTTP-Caching überspringen, da sonst inkonsistente Ergebnisse erzielt werden.

Was ist API-Test ?

Beim API-Testen wird die Programmierung verwendet, um Aufrufe an die API zu senden und den Ertrag zu ermitteln. Beim Testen wird das zu testende Segment als Black Box betrachtet. Das Ziel von API-Tests besteht darin, die ordnungsgemäße Ausführung und Fehlerbehandlung des Teils zu bestätigen, bevor es zu einer Anwendung koordiniert wird.

REST-API

REST: Repräsentativer Staatstransfer.

• Es ist eine Anordnung von Funktionen, für die die Tester Anforderungen ausführen und Antworten erhalten. In der REST-API werden Interaktionen über das HTTP-Protokoll durchgeführt.
• REST ermöglicht auch die Kommunikation zwischen Computern über ein Netzwerk.
• Zum Senden und Empfangen von Nachrichten werden HTTP-Methoden verwendet, und im Gegensatz zu Webdiensten ist keine strikte Nachrichtendefinition erforderlich.
• REST-Nachrichten akzeptieren das Formular häufig entweder in Form von XML oder in JavaScript Object Notation (JSON).

4 Häufig verwendete API-Methoden: -

1. GET: - Es bietet schreibgeschützten Zugriff auf eine Ressource.
2. POST: - Wird zum Erstellen oder Aktualisieren einer neuen Ressource verwendet.
3. PUT: - Es wird verwendet, um eine vorhandene Ressource zu aktualisieren oder zu ersetzen oder eine neue Ressource zu erstellen.
4. LÖSCHEN: - Wird zum Entfernen einer Ressource verwendet.

Schritte zum manuellen Testen der API: -

Um die API manuell zu verwenden, können wir browserbasierte REST-API-Plugins verwenden.

1. Installieren Sie das POSTMAN (Chrome) / REST (Firefox) Plugin
2. Geben Sie die API-URL ein
3. Wählen Sie die REST-Methode
4. Wählen Sie Content-Header
5. Geben Sie Request JSON (POST) ein.
6. Klicken Sie auf Senden
7. Es wird eine Ausgabeantwort zurückgegeben

Schritte zum Automatisieren der REST-API

Dies wird überall weniger erwähnt, aber das Richardson-Reifegradmodell ist eine der besten Methoden, um tatsächlich zu beurteilen, wie erholsam die API ist. Mehr dazu hier:

Richardson's Reifegradmodell

Ich würde sagen, dass ein wichtiger Baustein für das Verständnis von REST in den Endpunkten oder Zuordnungen liegt, wie z /customers/{id}/balance.

Sie können sich einen solchen Endpunkt als Verbindungspipeline von der Website (Front-End) zu Ihrer Datenbank / Ihrem Server (Back-End) vorstellen. Mit ihnen kann das Front-End Back-End-Operationen ausführen, die in den entsprechenden Methoden jeder REST-Zuordnung in Ihrer Anwendung definiert sind.