Öhm, die Antwort von Spike liegt irgendwo in der Grauzone zwischen richtig und falsch, nichts für ungut
Der Unterschied zwischen REST und RPC ist schon deren Bedeutung. RPC (Remote Procedure Call) definiert eine Serialisierung eines Funktionsaufrufs und der Antwort, du kannst also von einem Rechner je nach Implementierung beim Client eine Funktion ganz transparent auf einem Server aufrufen, du würdest keinen Unterschied sehen.
REST (Representational State Transfer) hingegen hat keine so festen Anforderungen. Du definierst einfach wo (URI) welche Daten in welcher Form liegen und wie du mit diesen interagieren kannst (HTTP Methoden). Dabei gibt es keinen festen Standard wie bei RPC sondern alles ist Auslegungssache und es gibt eben nur eine Hand voll Best Practises.
Man kann nicht einfach sagen, dass eines besser als das andere ist. Aber RPC hat schon viele Designprobleme:
Der Aufruf beim Client soll sich bei der Programmierung wie ein lokaler Aufruf verhalten, aber er ist viel langsamer (RTT). Dann kann dieser auch noch fehlschlagen, wenn der Server nicht erreichbar ist. Dann ist das Netzwerk immer eine Fehlerquelle, wie stellt man sicher, dass der Aufruf beim Server wirklich ausgeführt wird? Wie dass er nicht mehrmals ausgeführt wird? Da haben dann schlaue Personen die Semantiken Maybe, At-Least-One, At-Most-Once, Exactly-Once erfunden um verschiedene Verhalten zu beschreiben, wie oft der Aufruf beim Server nun ausgeführt wird. Und und und...
Man versuchte die Netzwerkkommunikation mit RPC zu vereinfachen aber hat diese einfach nur höllisch kompliziert. Bei REST muss der Implementierer eben entscheiden, was er macht, wenn er den Server nicht erreicht, denn REST definiert nur quasi ein Datenformat und erlaubte Operationen.
Du hast also einerseits RPC, welches fest in einem allgemeinen Standard definiert wie Aktionen ausgeführt werden und auf der anderen Seite REST das je nach Anwendung alles anders definieren kann.
Nimm REST, denn RPC hat bei Webanwendungen quasi gar keine Bedeutung.
