REST gegen JSON-RPC? [geschlossen]

Ich versuche, zwischen REST und JSON-RPC zu wählen, um eine API für eine Webanwendung zu entwickeln. Wie vergleichen sie?

Update 2015: Ich habe festgestellt, dass REST für eine API, die über Web / HTTP bereitgestellt wird, einfacher zu entwickeln und zu verwenden ist, da das vorhandene und ausgereifte HTTP-Protokoll, das sowohl vom Client als auch vom Server verstanden wird, von der API genutzt werden kann. Beispielsweise können Antwortcodes, Header, Abfragen, Post-Body, Caching und viele andere Funktionen von der API ohne zusätzlichen Aufwand oder Einrichtung verwendet werden.

Das grundlegende Problem bei RPC ist die Kopplung. RPC-Clients sind auf verschiedene Weise eng mit der Service-Implementierung verbunden, und es wird sehr schwierig, die Service-Implementierung zu ändern, ohne die Clients zu beschädigen:

• Clients müssen die Prozedurnamen kennen.
• Prozedurparameter Reihenfolge, Typen und Anzahl sind wichtig. Es ist nicht so einfach, Prozedursignaturen (Anzahl der Argumente, Reihenfolge der Argumente, Argumenttypen usw.) auf der Serverseite zu ändern, ohne die Client-Implementierungen zu beschädigen.
• Der RPC-Stil macht nur Prozedurendpunkte + Prozedurargumente verfügbar. Für den Kunden ist es unmöglich zu bestimmen, was als nächstes getan werden kann.

Andererseits ist es im REST-Stil sehr einfach, Clients zu führen, indem Steuerinformationen in Darstellungen (HTTP-Header + Darstellung) aufgenommen werden. Beispielsweise:

• Es ist möglich (und tatsächlich obligatorisch), Links einzubetten, die mit Linkbeziehungstypen versehen sind, die die Bedeutung dieser URIs vermitteln.
• Client-Implementierungen müssen nicht von bestimmten Prozedurnamen und Argumenten abhängen. Stattdessen hängen Clients von Nachrichtenformaten ab. Dies schafft die Möglichkeit, bereits implementierte Bibliotheken für bestimmte Medienformate (z. B. Atom, HTML, Collection + JSON, HAL usw.) zu verwenden.
• Es ist möglich, URIs einfach zu ändern, ohne Clients zu beschädigen, sofern sie nur von registrierten (oder domänenspezifischen) Linkbeziehungen abhängen.
• Es ist möglich, formularähnliche Strukturen in Darstellungen einzubetten, sodass Kunden diese Beschreibungen als UI-Funktionen verfügbar machen können, wenn der Endbenutzer ein Mensch ist.
• Die Unterstützung für das Caching ist ein zusätzlicher Vorteil.
• Standardisierte Statuscodes;

Auf der REST-Seite gibt es viele weitere Unterschiede und Vorteile.

Ich habe das Problem eingehend untersucht und festgestellt, dass reines REST viel zu einschränkend und RPC am besten ist, obwohl die meisten meiner Apps CRUD-Apps sind. Wenn Sie sich an REST halten, werden Sie sich irgendwann am Kopf kratzen und sich fragen, wie Sie Ihrer API für einen bestimmten Zweck auf einfache Weise eine weitere erforderliche Methode hinzufügen können. In vielen Fällen besteht die einzige Möglichkeit, dies mit REST zu tun, darin, einen anderen Controller dafür zu erstellen, was Ihr Programm übermäßig komplizieren kann.

Wenn Sie sich für RPC entscheiden, besteht der einzige Unterschied darin, dass Sie das Verb explizit als Teil der URI angeben. Dies ist klar, konsistent, weniger fehlerhaft und wirklich kein Problem. Insbesondere wenn Sie eine App erstellen, die weit über einfaches CRUD hinausgeht, ist RPC der einzige Weg. Ich habe ein weiteres Problem mit RESTful-Puristen: HTTP POST, GET, PUT, DELETE haben bestimmte Bedeutungen in HTTP, die von REST in andere Bedeutungen umgewandelt wurden, einfach weil sie die meiste Zeit passen - aber nicht immer.

Beim Programmieren habe ich vor langer Zeit festgestellt, dass der Versuch, eine Sache zu verwenden, um zwei Dinge zu bedeuten, irgendwann auftauchen und Sie beißen wird. Ich möchte die Möglichkeit haben, POST für nahezu jede Aktion zu verwenden, da es die Freiheit bietet, Daten zu senden und zu empfangen, wie es Ihre Methode erfordert. Sie können nicht die ganze Welt in CRUD einpassen.

Erstens ist HTTP-REST eine Architektur für die Übertragung von Repräsentationszuständen. Dies impliziert viele interessante Dinge:

• Ihre API ist zustandslos und daher viel einfacher zu entwerfen (es ist wirklich einfach, einen Übergang in einem komplexen Automaten zu vergessen) und in unabhängige Softwareteile zu integrieren.
• Sie werden dazu gebracht, Lesemethoden als sichere zu entwerfen , die einfach zwischenzuspeichern und zu integrieren sind.
• Sie werden dazu gebracht, Schreibmethoden als idempotente zu entwerfen , die viel besser mit Zeitüberschreitungen umgehen.

Zweitens ist HTTP-REST vollständig mit HTTP kompatibel (siehe "sicher" und "idempotent" im vorherigen Teil). Daher können Sie HTTP-Bibliotheken (für jede vorhandene Sprache vorhanden) und HTTP-Reverse-Proxys wiederverwenden, die Sie erhalten die Fähigkeit, erweiterte Funktionen (Cache, Authentifizierung, Komprimierung, Umleitung, Umschreiben, Protokollierung usw.) ohne Codezeile zu implementieren.

Last but not least ist die Verwendung von HTTP als RPC-Protokoll laut dem Entwickler von HTTP 1.1 (und Erfinder von REST) ​​ein großer Fehler: http://www.ics.uci.edu/~fielding/pubs/dissertation/evaluation. htm # sec_6_5_2

Tolle Antworten - wollte nur einige der Kommentare klarstellen. JSON-RPC ist schnell und einfach zu konsumieren, aber wie bereits erwähnt, sind Ressourcen und Parameter eng miteinander verbunden und es besteht die Tendenz, dass Verben (api / deleteUser, api / addUser) mit GET / POST verwendet werden, wobei REST lose gekoppelte Ressourcen (api / Benutzer), die in einer HTTP-REST-API auf mehreren HTTP-Methoden (GET, POST, PUT, PATCH, DELETE) basieren. REST ist für unerfahrene Entwickler etwas schwieriger zu implementieren, aber der Stil ist mittlerweile weit verbreitet und bietet auf lange Sicht viel mehr Flexibilität (was Ihrer API eine längere Lebensdauer verleiht).

REST verfügt nicht nur über keine eng gekoppelten Ressourcen, sondern verhindert auch, dass Sie sich auf einen einzelnen Inhaltstyp festlegen. Dies bedeutet, dass Ihr Client die Daten in XML, JSON oder sogar YAML empfangen muss, sofern dies in Ihr System integriert ist Geben Sie alle Benutzer zurück, die die Header content-type / accept verwenden.

Auf diese Weise können Sie Ihre API flexibel genug halten, um neue Inhaltstypen ODER Clientanforderungen zu unterstützen.

Was REST jedoch wirklich von JSON-RPC unterscheidet, ist, dass es einer Reihe sorgfältig durchdachter Einschränkungen folgt, um die Flexibilität der Architektur zu gewährleisten. Zu diesen Einschränkungen gehört, dass sichergestellt wird, dass sich Client und Server unabhängig voneinander entwickeln können (Sie können Änderungen vornehmen, ohne die Anwendung Ihres Clients zu beschädigen), dass die Anrufe zustandslos sind (Status wird durch Hypermedia dargestellt), dass eine einheitliche Schnittstelle für Interaktionen bereitgestellt wird. Die API wird auf einem Schichtsystem entwickelt und die Antwort kann vom Client zwischengespeichert werden. Es gibt auch eine optionale Einschränkung für die Bereitstellung von Code bei Bedarf.

Nach alledem sind die meisten APIs (laut Fielding) nicht REST-fähig, da sie keine Hypermedien enthalten (eingebettete Hypertext-Links in der Antwort, die beim Navigieren in der API helfen). Die meisten APIs, die Sie dort finden, sind REST-ähnlich, da sie den meisten REST-Konzepten folgen, diese Einschränkung jedoch ignorieren. Immer mehr APIs implementieren dies jedoch und es wird immer mehr zu einer gängigen Praxis.

Dies gibt Ihnen auch eine gewisse Flexibilität, da hypermediengesteuerte APIs (wie z. B. Stormpath) den Client zu den URIs leiten (dh wenn sich etwas ändert, können Sie den URI in bestimmten Fällen ohne negative Auswirkungen ändern), wie dies bei RPC-URIs erforderlich ist statisch. Mit RPC müssen Sie diese verschiedenen URIs auch ausführlich dokumentieren und erklären, wie sie im Verhältnis zueinander funktionieren.

Im Allgemeinen würde ich sagen, dass REST der richtige Weg ist, wenn Sie eine erweiterbare, flexible API erstellen möchten, die eine lange Lebensdauer hat. Aus diesem Grund würde ich sagen, dass dies in 99% der Fälle der richtige Weg ist.

Viel Glück, Mike

IMO, der entscheidende Punkt ist die Ausrichtung von Aktion und Ressource. REST ist ressourcenorientiert und eignet sich gut für CRUD-Operationen. Aufgrund seiner bekannten Semantik bietet es einem ersten Benutzer eine gewisse Vorhersehbarkeit. Wenn es jedoch anhand von Methoden oder Prozeduren implementiert wird, müssen Sie eine künstliche Übersetzung für die ressourcenzentrierte Welt bereitstellen. Auf der anderen Seite eignet sich RPC perfekt für aktionsorientierte APIs, bei denen Sie Dienste und keine CRUD-fähigen Ressourcensätze verfügbar machen.

Zweifellos ist REST beliebter. Dies fügt definitiv einige Punkte hinzu, wenn Sie die API einem Dritten zugänglich machen möchten.

Wenn nicht (zum Beispiel beim Erstellen eines AJAX-Frontends in einem SPA), habe ich die Wahl zwischen RPC. Insbesondere JSON-RPC, kombiniert mit JSON-Schema als Beschreibungssprache, und je nach Anwendungsfall über HTTP oder Websockets transportiert.

JSON-RPC ist eine einfache und elegante Spezifikation, die JSON-Nutzdaten für Anforderungen und Antworten definiert, die in synchronen oder asynchronen RPCs verwendet werden sollen.

Das JSON-Schema ist ein Entwurf einer Spezifikation, die ein JSON-basiertes Format definiert, mit dem JSON-Daten beschrieben werden sollen. Durch die Beschreibung Ihrer Service-Eingabe- und Ausgabe-Nachrichten mithilfe des JSON-Schemas können Sie eine beliebige Komplexität in der Nachrichtenstruktur aufweisen, ohne die Benutzerfreundlichkeit zu beeinträchtigen, und die Service-Integration kann automatisiert werden.

Die Wahl des Transportprotokolls (HTTP vs. Websockets) hängt von verschiedenen Faktoren ab. Dies ist am wichtigsten, ob Sie HTTP-Funktionen (Caching, Revalidierung, Sicherheit, Idempotenz, Inhaltstyp, mehrteilig usw.) benötigen oder ob Ihre Anwendung ausgetauscht werden muss Nachrichten mit hohen Frequenzen.

Bis jetzt ist es sehr meine persönliche Meinung zu diesem Thema, aber jetzt etwas, das für die Java-Entwickler, die diese Zeilen lesen, sehr hilfreich sein kann. Das Framework, an dem ich im letzten Jahr gearbeitet habe, ist aus derselben Frage entstanden, die Sie sich jetzt fragen ::

http://rpc.brutusin.org

Hier sehen Sie eine Live-Demo mit dem integrierten Repository-Browser für Funktionstests (dank JSON-Schema) und einer Reihe von Beispieldiensten:

http://demo.rpc.brutusin.org

Hoffe es hilft sich zu paaren!

Nacho

Wenn Ihr Service nur mit Modellen und dem Muster GET / POST / PUT / DELETE einwandfrei funktioniert, verwenden Sie reines REST.

Ich bin damit einverstanden, dass HTTP ursprünglich für zustandslose Anwendungen entwickelt wurde.

Aber für moderne, komplexere (!) Echtzeitanwendungen (Webanwendungen), bei denen Sie Websockets verwenden möchten (was häufig Statefulness impliziert), warum nicht beide verwenden? JSON-RPC über Websockets ist sehr leicht, sodass Sie die folgenden Vorteile haben:

• Sofortige Aktualisierungen auf jedem Client (definieren Sie Ihren eigenen Server-zu-Client-RPC-Aufruf zum Aktualisieren der Modelle)
• Einfache Komplexität hinzufügen (versuchen Sie, einen Etherpad-Klon nur mit REST zu erstellen)
• Wenn Sie es richtig machen (fügen Sie RPC nur als Extra für Echtzeit hinzu), können die meisten weiterhin nur mit REST verwendet werden (außer wenn die Hauptfunktion ein Chat oder etwas anderes ist).

Da Sie nur die serverseitige API entwerfen, beginnen Sie mit der Definition von REST-Modellen und fügen Sie später nach Bedarf JSON-RPC-Unterstützung hinzu, um die Anzahl der RPC-Aufrufe auf ein Minimum zu beschränken.

(und entschuldigen Sie die übermäßige Verwendung von Klammern)

Ich war in der Vergangenheit ein großer Fan von REST und es hat viele Vorteile gegenüber RPC auf Papier. Sie können dem Client verschiedene Inhaltstypen, Caching, Wiederverwendung von HTTP-Statuscodes präsentieren, Sie können den Client durch die API führen und Sie können Dokumentation in die API einbetten, wenn diese ohnehin nicht selbsterklärend ist.

Aber ich habe die Erfahrung gemacht, dass dies in der Praxis nicht hält und Sie stattdessen viel unnötige Arbeit leisten, um alles richtig zu machen. Außerdem werden die HTTP-Statuscodes häufig nicht genau Ihrer Domänenlogik zugeordnet, und die Verwendung in Ihrem Kontext ist häufig etwas erzwungen. Das Schlimmste an REST ist meiner Meinung nach, dass Sie viel Zeit damit verbringen, Ihre Ressourcen und die damit verbundenen Interaktionen zu gestalten. Und wenn Sie einige wichtige Ergänzungen an Ihrer API vornehmen, hoffen Sie, dass Sie eine gute Lösung finden, um die neue Funktionalität hinzuzufügen, und Sie haben sich noch nicht in einer Ecke entworfen.

Dies ist für mich oft eine Zeitverschwendung, da ich die meiste Zeit bereits eine sehr gute und offensichtliche Vorstellung davon habe, wie eine API als eine Reihe von Remoteprozeduraufrufen modelliert werden kann. Und wenn ich all diese Anstrengungen unternommen habe, um mein Problem innerhalb der Einschränkungen von REST zu modellieren, ist das nächste Problem, wie ich es vom Client aus aufrufen kann. Unsere Programme basieren auf dem Aufrufen von Prozeduren, sodass das Erstellen einer guten RPC-Clientbibliothek einfach ist. Das Erstellen einer guten REST-Clientbibliothek ist weniger wichtig. In den meisten Fällen werden Sie einfach von Ihrer REST-API auf dem Server einer Reihe von Prozeduren in Ihrem Client zuordnen Bibliothek.

Aus diesem Grund fühlt sich RPC für mich heute viel einfacher und natürlicher an. Was ich jedoch wirklich vermisse, ist ein konsistentes Framework, das es einfach macht, selbst beschreibende und interoperable RPC-Dienste zu schreiben. Deshalb habe ich mein eigenes Projekt erstellt, um mit neuen Möglichkeiten zu experimentieren, um RPC für mich einfacher zu machen, und vielleicht findet es auch jemand anderes nützlich: https://github.com/aheck/reflectrpc

Nach dem Richardson-Reifegradmodell lautet die Frage nicht REST vs. RPC , sondern wie viel REST ?

In dieser Ansicht kann die Einhaltung des REST-Standards in 4 Stufen eingeteilt werden.

• Stufe 0: Denken Sie in Aktionen und Parametern. Wie der Artikel erklärt, entspricht dies im Wesentlichen JSON-RPC (der Artikel erklärt es für XML-RPC, aber für beide gelten dieselben Argumente).
• Stufe 1: Denken Sie in Ressourcen. Alles, was für eine Ressource relevant ist, gehört zur selben URL
• Stufe 2: Verwenden Sie HTTP-Verben
• Level 3: HATEOAS

Laut dem Ersteller des REST-Standards können nur Level 3-Services als RESTful bezeichnet werden. Dies ist jedoch eine Metrik der Konformität , nicht der Qualität. Wenn Sie nur eine Remote-Funktion aufrufen möchten, die eine Berechnung durchführt, ist es wahrscheinlich nicht sinnvoll, relevante Hypermedia-Links in der Antwort zu haben, und auch keine Differenzierung des Verhaltens anhand des verwendeten HTTP-Verbs. Ein solcher Aufruf ist also von Natur aus eher RPC-ähnlich. Ein niedrigeres Compliance-Niveau bedeutet jedoch nicht unbedingt Statefulness oder höhere Kopplung. Anstatt an REST vs. RPC zu denken , sollten Sie wahrscheinlich so viel REST wie möglich verwenden, aber nicht mehr. Verdrehen Sie Ihre Anwendung nicht nur, um den RESTful-Compliance-Standards zu entsprechen.

Warum JSON RPC:

Bei REST-APIs müssen wir für jede Funktionalität / Methode, die wir möglicherweise benötigen, einen Controller definieren. Wenn wir also 10 Methoden haben, auf die ein Client zugreifen soll, müssen wir 10 Controller schreiben, um die Anforderung des Clients mit einer bestimmten Methode zu verbinden.

Ein weiterer Faktor ist, dass der Client sich daran erinnern muss, ob er POST oder GET verwenden soll, obwohl wir für jede Methode / Funktionalität unterschiedliche Controller haben. Dies macht die Sache noch komplizierter. Darüber hinaus muss zum Senden von Daten der Inhaltstyp der Anforderung festgelegt werden, wenn POST verwendet wird.

Im Fall von JSON RPC werden die Dinge stark vereinfacht, da die meisten JSONRPC-Server mit POST-HTTP-Methoden arbeiten und der Inhaltstyp immer application / json ist. Dies entlastet das Erinnern daran, die richtigen HTTP-Methoden- und Inhaltseinstellungen auf der Clientseite zu verwenden.

Es müssen keine separaten Controller für verschiedene Methoden / Funktionen erstellt werden, die der Server einem Client zur Verfügung stellen möchte.

Warum ruhen:

Sie haben separate URLs für verschiedene Funktionen, die der Server für den Client verfügbar machen möchte. Infolgedessen können Sie diese URLs einbetten.

Die meisten dieser Punkte sind umstritten und hängen vollständig von den Bedürfnissen einer Person ab.

Ich denke, wie immer kommt es darauf an ...

REST hat den großen Vorteil einer breiten öffentlichen Unterstützung und dies bedeutet viele Tools und Bücher. Wenn Sie eine API erstellen müssen, die von einer großen Anzahl von Verbrauchern aus verschiedenen Organisationen verwendet wird, ist dies nur aus einem Grund der richtige Weg: Sie ist beliebt. Als Protokoll ist es natürlich ein totaler Fehler, da es zu viele völlig verschiedene Möglichkeiten gibt, einen Befehl einer URL / einem Verb / einer Antwort zuzuordnen.

Wenn Sie eine einseitige Web-App schreiben, die mit einem Backend kommunizieren muss, ist REST meiner Meinung nach viel zu komplex. In dieser Situation müssen Sie sich keine Sorgen um die langfristige Kompatibilität machen, da App und API gemeinsam weiterentwickelt werden können.

Ich habe einmal mit REST für eine einseitige Web-App angefangen, aber die fein abgestimmten Befehle zwischen der Web-App und dem Server haben mich schnell verrückt gemacht. Soll ich es als Pfadparameter codieren? Im Körper? Ein Abfrageparameter? Ein Header? Nach dem URL / Verb / Response-Design musste ich dieses Durcheinander dann in Javascript, den Decoder in Java, codieren und dann die eigentliche Methode aufrufen. Obwohl es viele Tools dafür gibt, ist es wirklich schwierig, keine HTTP-Semantik in Ihren Domain-Code zu bekommen, was wirklich eine schlechte Praxis ist. (Zusammenhalt)

Versuchen Sie, eine Swagger / OpenAPI-Datei für eine mittelkomplexe Site zu erstellen, und vergleichen Sie diese mit einer einzelnen Java-Schnittstelle, die die Remoteprozeduren in dieser Datei beschreibt. Der Komplexitätsanstieg ist atemberaubend.

Ich habe daher für die einseitige Webanwendung von REST zu JSON-RPC gewechselt. aIch habe eine winzige Bibliothek entwickelt, die eine Java-Schnittstelle auf dem Server codiert und an den Browser gesendet hat. Im Browser wurde ein Proxy für den Anwendungscode erstellt, der für jede Funktion ein Versprechen zurückgab.

Auch hier hat REST seinen Platz, nur weil es berühmt ist und daher gut unterstützt wird. Es ist auch wichtig, die zugrunde liegende Philosophie der zustandslosen Ressourcen und das hierarchische Modell zu erkennen. Diese Prinzipien können jedoch genauso einfach in einem RPC-Modell verwendet werden. JSON RPC funktioniert über HTTP und bietet daher in diesem Bereich die gleichen Vorteile wie REST. Der Unterschied besteht darin, dass Sie nicht gezwungen sind, unnötige Arbeit zu leisten, wenn Sie unweigerlich auf diese Funktionen stoßen, die diesen Prinzipien nicht gut entsprechen.

REST ist eng mit HTTP gekoppelt. Wenn Sie also Ihre API nur über HTTP verfügbar machen, ist REST für die meisten (aber nicht alle) Situationen besser geeignet. Wenn Sie Ihre API jedoch über andere Transporte wie Messaging oder Web-Sockets verfügbar machen müssen, ist REST einfach nicht anwendbar.

Es ist besser, JSON-RPC zwischen REST und JSON-RPC zu wählen, um eine API für eine Webanwendung zu entwickeln, die leichter zu verstehen ist. JSON-RPC wird bevorzugt, da seine Zuordnung zu Methodenaufrufen und Kommunikationen leicht verständlich ist.

Die Wahl des am besten geeigneten Ansatzes hängt von den Einschränkungen oder dem Hauptziel ab. Wenn beispielsweise die Leistung ein Hauptmerkmal ist, ist es ratsam, sich für JSON-RPC zu entscheiden (z. B. High Performance Computing). Wenn das Hauptziel jedoch darin besteht, agnostisch zu sein, um eine generische Schnittstelle anzubieten, auf die andere schließen können, ist es ratsam, sich für REST zu entscheiden. Wenn Sie beide Ziele erreichen möchten, ist es ratsam, beide Protokolle einzuschließen.

Die Tatsache, die REST tatsächlich von JSON-RPC trennt, ist, dass es eine Reihe sorgfältig durchdachter Einschränkungen verfolgt, die die architektonische Flexibilität bestätigen. Die Einschränkungen bestehen darin, sicherzustellen, dass sowohl der Client als auch der Server unabhängig voneinander wachsen können (Änderungen können vorgenommen werden, ohne die Anwendung des Clients zu beeinträchtigen). Die Anrufe sind zustandslos (der Status wird als Hypermedia angesehen) und einheitlich Schnittstelle wird für Interaktionen angeboten, die API wird auf einem Schichtsystem erweitert (Hall, 2010). JSON-RPC ist schnell und einfach zu konsumieren. Wie bereits erwähnt, sind Ressourcen und Parameter eng miteinander verbunden, und es hängt wahrscheinlich von Verben (api / addUser, api / deleteUser) ab, die GET / POST verwenden, während REST lose gekoppelte Ressourcen (api) liefert / users) in einem HTTP. Die REST-API hängt von verschiedenen HTTP-Methoden ab, z. B. GET, PUT, POST, DELETE, PATCH.

JSON (als JavaScript Object Notation bezeichnet) ist ein leichtes Datenaustauschformat, das für Menschen sowohl lesbar als auch schreibbar ist. Maschinen können problemlos analysieren und generieren. JSON ist ein Textformat, das vollständig sprachunabhängig ist, jedoch Konventionen praktiziert, die Programmierern der Sprachfamilie bekannt sind und aus C #, C, C ++, Java, Perl, JavaScript, Python und zahlreichen anderen bestehen. Solche Eigenschaften machen JSON zu einer perfekten Datenaustauschsprache und zu einer besseren Wahl.

Falsche Frage: Erlegt einen Manichäer auf, der nicht existiert!

Sie können JSON-RPC mit "weniger Verb" (keine Methode ) verwenden und die minimale Standardisierung beibehalten, die für die Sendo-ID, Parameter, Fehlercodes und Warnmeldungen erforderlich ist . Der JSON-RPC-Standard sagt nicht "Sie können nicht REST sein", sondern nur, wie grundlegende Informationen gepackt werden.

"REST JSON-RPC" existiert ! ist REST mit "Best Practices" für minimales Packen von Informationen mit einfachen und soliden Verträgen.

Beispiel

(aus dieser Antwort und dem didaktischen Kontext)

Beim Umgang mit REST ist es im Allgemeinen hilfreich, zunächst in Ressourcen zu denken. In diesem Fall ist die Ressource nicht nur "Bankkonto", sondern eine Transaktion dieses Bankkontos ... JSON-RPC verpflichtet den Parameter "method" jedoch nicht, alle werden durch den "Pfad" des Endpunkts codiert.

• REST Einzahlung mit POST /Bank/Account/John/Transactionmit JSON-Anfrage {"jsonrpc": "2.0", "id": 12, "params": {"currency":"USD","amount":10}}.
  Die JSON-Antwort kann etwas wie sein{"jsonrpc": "2.0", "result": "sucess", "id": 12}

• REST Zurückziehen mit POST /Bank/Account/John/Transaction... ähnlich.

• ... GET /Bank/Account/John/Transaction/12345@13... Dies könnte einen JSON-Datensatz dieser genauen Transaktion zurückgeben (z. B. möchten Ihre Benutzer im Allgemeinen einen Datensatz mit Belastungen und Gutschriften auf ihrem Konto). Etwas wie {"jsonrpc": "2.0", "result": {"debits":[...],"credits":[...]}, "id": 13}. Die Konvention über (REST) ​​GET-Anforderung kann die Codierung der ID durch "@id" enthalten, sodass kein JSON gesendet werden muss, aber dennoch JSON-RPC im Antwortpaket verwendet wird.

Wenn Sie Ressourcen anfordern, ist die RESTful-API von Natur aus besser. Wenn Sie komplizierte Daten mit vielen anderen Parametern und komplizierten Methoden als einfachem CRUD anfordern, ist RPC der richtige Weg.

Ich verwende vdata für das RPC-Protokoll: http://vdata.dekuan.org/

1, PHP und JavaScript sind beide in Ordnung. 2, CORS-Aufruf (Cross-Origin Resource Sharing) ist weiterhin in Ordnung.