这里有很多很好的答案。我仍然建议你参考谷歌的这个博客，因为它在讨论RPC和REST之间的区别方面做得非常好，并抓住了一些我在这里的任何答案中都没有读到的东西。

我想引用同一链接中的一段话，这段话让我印象深刻:

REST itself is a description of the design principles that underpin HTTP and the world-wide web. But because HTTP is the only commercially important REST API, we can mostly avoid discussing REST and just focus on HTTP. This substitution is useful because there is a lot of confusion and variability in what people think REST means in the context of APIs, but there is much greater clarity and agreement on what HTTP itself is. The HTTP model is the perfect inverse of the RPC model—in the RPC model, the addressable units are procedures, and the entities of the problem domain are hidden behind the procedures. In the HTTP model, the addressable units are the entities themselves and the behaviors of the system are hidden behind the entities as side-effects of creating, updating, or deleting them.

在HTTP上，它们都只是HttpRequest对象，它们都期望返回一个HttpResponse对象。我认为人们可以继续用这种描述来编码，而不用担心其他的事情。

您不能仅仅通过查看您发布的内容来明确区分REST或RPC。

REST的一个约束是它必须是无状态的。如果你有一个会话，那么你就有一个状态，所以你不能把你的服务称为RESTful的。

事实上，您在URL中有一个操作(即getAllData)是对RPC的指示。在REST中，您交换表示，您执行的操作由HTTP谓词指定。同样，在REST中，内容协商不是使用?p={JSON}参数执行的。

不知道您的服务是否是RPC，但它不是RESTful的。你可以在网上了解它们的区别，这里有一篇文章可以让你开始:揭穿RPC和REST的神话。您更了解服务内部的内容，因此将其函数与RPC进行比较，并得出自己的结论。

共享的URL看起来像RPC端点。 下面是RPC和REST的示例。希望这有助于理解什么时候可以使用它们。

让我们考虑一个端点，它向客户发送应用程序维护中断电子邮件。

这个端点执行一个特定的操作。

RPC

POST https://localhost:8080/sendOutageEmails

BODY: {"message": "we have a scheduled system downtime today at 1 AM"}

REST

POST https://localhost:8080/emails/outage

BODY: {"message": "we have a scheduled system downtime today at 1 AM"}

在这种情况下，RPC端点更适合使用。当API调用执行单个任务或操作时，通常使用RPC端点。显然，我们可以使用REST，但端点不是很REST化的，因为我们没有对资源执行操作。

现在让我们看看在数据库中存储一些数据的端点。(典型CRUD操作)

RPC

POST https://localhost:8080/saveBookDetails

BODY: {"id": "123", "name": "book1", "year": "2020"}

REST

POST https://localhost:8080/books

BODY: {"id": "123", "name": "book1", "year": "2020"}

REST对于这种情况(CRUD)要好得多。在这里，读取(GET)或删除(delete)或更新(PUT)可以通过使用适当的HTTP方法来完成。方法决定对资源(在本例中为“books”)的操作。 在这里使用RPC是不合适的，因为我们需要为每个CRUD操作(/getBookDetails， /deleteBookDetails， /updateBookDetails)设置不同的路径，并且必须为应用程序中的所有资源执行此操作。

总而言之,

RPC可用于执行单个特定操作的端点。 资源需要CRUD操作的端点的REST。

REST最好被描述为与资源一起工作，而RPC更多地是关于操作。

休息 代表具象状态传输。这是一种组织独立系统之间交互的简单方法。 RESTful应用程序通常使用HTTP请求来发布数据(创建和/或更新)、读取数据(例如，进行查询)和删除数据。因此，REST可以将HTTP用于所有四个CRUD(创建/读取/更新/删除)操作。

RPC 主要用于跨不同模块通信，以服务用户请求。 例如，在openstack中，nova、glance和neutron在启动虚拟机时是如何协同工作的。

考虑下面的HTTP api示例，该示例模拟餐厅中的订单。

The RPC API thinks in terms of "verbs", exposing the restaurant functionality as function calls that accept parameters, and invokes these functions via the HTTP verb that seems most appropriate - a 'get' for a query, and so on, but the name of the verb is purely incidental and has no real bearing on the actual functionality, since you're calling a different URL each time. Return codes are hand-coded, and part of the service contract. The REST API, in contrast, models the various entities within the problem domain as resources, and uses HTTP verbs to represent transactions against these resources - POST to create, PUT to update, and GET to read. All of these verbs, invoked on the same URL, provide different functionality. Common HTTP return codes are used to convey status of the requests.

下单:

RPC: http://MyRestaurant:8080/Orders/PlaceOrder (POST: {Tacos对象}) REST: http://MyRestaurant:8080/Orders/Order?OrderNumber=asdf (POST: {Tacos对象})

检索订单:

RPC: http://MyRestaurant:8080/Orders/GetOrder?OrderNumber=asdf (GET) 休息:http://MyRestaurant:8080/Orders/Order?OrderNumber=asdf (GET)

更新订单:

RPC: http://MyRestaurant:8080/Orders/UpdateOrder (PUT:{菠萝玉米饼对象}) REST: http://MyRestaurant:8080/Orders/Order?OrderNumber=asdf (PUT:{菠萝玉米饼对象})

示例取自sites.google.com/site/wagingguerillasoftware/rest-series/what-is-restful-rest-vs-rpc