RPC 与 Restful 端点

Question

我花费了比我愿意承认的更多的时间来尝试理解 RPC 和 Restful 端点之间的差异。事实上，在深入这个兔子洞之后，我什至不确定我是否完全理解 RPC 是什么了。我并不孤单。我看到无数的消息反复要求澄清。

到目前为止我的理解是：

RPC 和 Restful 端点本质上很大程度上只是概念性的。没有标准。

两者都是调用远程服务器上的函数的方法。

对于静态端点，我们将 HTTP 方法映射到资源上的 CRUD 操作。

对于 RPC，我们关心的是对象上的操作。

然而，在这两种情况下，我们都在解决远程方法调用。

我读过一些人说，宁静不应该是有状态的，如果是的话，那就不是宁静的。但是大多数宁静的端点不是通过会话使用状态吗？我的意思是，我不会让任何人在未登录的情况下删除数据。

我还读到像domain(.)com/login 这样的函数并不是安静的，因为它是一个动作。这似乎是有道理的，但由于我在服务器上编写的函数与简单的 Restful 函数没有任何不同，所以我们如何称呼它们（Restful 与 RPC）真的很重要吗？

我真的不明白我错过了什么，而且迄今为止 StackOverflow 上似乎还没有帖子可以解决这个困惑。

希望有人能够使用上述内容作为理解指南提供一些见解。提前致谢。

Answer 1

It's an amazing question. There is a huge difference between REST and RPC approaches, I'll try to explain it.

RPC just lets you call some remote computer to make some job. It can be any job, and it can have any inputs and outputs. When you design API, you just define how to name this job operation and which inputs and outputs it will have.

Step 1. Just RPC

For example, you could have operation foo with one input and two outputs like that (I will use JSight API notation because it supports both RPC and REST API types):

JSIGHT 0.3

URL /rpc-api
  Protocol json-rpc-2.0
  Method foo
    Params
      {
        "input-1": 123 // some integer
      }
    Result
      {
        "output-1": 123, // some other integer
        "output-2": "some string"
      }

When you design your RPC API you can use as many such operations as you want.

So, what's the problem with this? Why do we need REST, if we already have RPC?

The problems are the following:

1. When you look at the method foo definition you do not have the slightest idea, what it does.
2. When you design RPC APIs you have absolute freedom, but freedom often can be a bad thing. Because people think in different fashions. You could think, that your API is easy and elegant, but other people would not think so.

Step 2. Standardized RPC

If you are an experienced API designer and you use the RPC style, you will try to follow some pattern to avoid the two faults mentioned above. For example, let's imagine, that your foo method returns a customer entity. Then you will never call it like foo, you will call it getCustomer, like this:

JSIGHT 0.3

URL /rpc-api
  Protocol json-rpc-2.0
  Method getCustomer
    Params
      {
        "input-1": 123 // some integer
      }
    Result
      {
        "output-1": 123, // some other integer
        "output-2": "some string"
      }

Ok! Now when you just look at this description, you can say, that this method returns a customer; that parameter input-1 is some filter, most possibly, ID; and output-1 and output-2 are some customer properties.

Look, just using the standard way of naming the method, we made our API much more easy-to-understand.

Still, why do we need REST? What's the problem here?

The problem is, that when you have dozens of such RPC methods, your API looks messy. E. g.:

JSIGHT 0.3

URL /rpc-api
  Protocol json-rpc-2.0
  Method getCustomer
  Method updateCustomer
  Method getCustomerFriends
  Method getCustomerFather
  Method askCustomerConfirmation
  # etc...

为什么这堆方法不容易理解呢？因为这不是我们大脑的工作方式。我们的大脑总是按实体对行为进行分组。你自然会想到一个实体，然后想到你可以用它做的行动。例如 你可以用杯子做什么？拿走、藏起来、打破、清洗、翻转。大脑很少首先考虑行为，然后考虑实体。我可以拿什么？杯子、球、冰淇淋、门票、妻子。不太自然。

那么，REST 是关于什么的呢？

步骤 3. 休息

REST 是关于对实体进行分组并使用这些实体定义最标准的操作。

在 IT 中，我们通常创建、读取、写入或删除实体。这就是为什么我们在 HTTP 中有POST、GET、PUT、 和DELETE方法，这实际上是 REST 风格的唯一实现。

当我们按实体对方法进行分组时，我们的 API 变得更加清晰。看：

JSIGHT 0.3

GET  /customer/{id}
PUT  /customer/{id}
GET  /customer/{id}/friends
GET  /customer/{id}/father
POST /customer/{id}/ask-confirmation

现在比上面的 RPC 风格的例子更容易理解。

结论

还有很多其他问题涉及 RPC 和 REST 之间的差异。REST 和 RPC 一样都有其缺点。但我想向你解释一下主要思想：

REST 是一个标准，可以帮助您以用户友好的方式组织 API，这对人脑来说很舒服，因此任何开发人员都可以快速捕获您的 API 结构。

RPC只是一种调用远程操作的方式。

上面所有的例子都集中在这里：https://editor.jsight.io/r/g6XJwjV/1