6

我正在做一个项目，我试图公开软件的功能。基本上我已经设置了后端，并且正在考虑使用 JSON msgs 将前端与后端代码分开。我对服务和 API 之间的区别有点困惑。我知道 API 可以建立在服务之上。但我想到了这两个模型——使用 json-rpc 访问配置文件 X

http://xyz.com/?request= {"jsonrpc":"2.0","id":1,"method":"getProfile","params":{"id":"X"}}

还是应该像这样使用 REST -

http://api.xyz.com/X

谢谢你

4

2 回答 2

22

“服务”与“API”是一个相当模糊的问题。通常，这两个术语可以互换使用。“REST”与“RPC”更容易解释。

通常使用 REST，URL 代表特定资源，例如“用户”、“帐户”等。通常，您可以使用 HTTP 方法 POST/GET/PUT/DELETE 创建/检索/更新/删除这些资源. 要更新用户 1125 的配置文件，您可以发送以下内容：

POST /user/1125 HTTP/1.1
Host: wherever.com
Content-type: application/x-www-form-urlencoded

firstName=Davey&lastName=Jones&email=dj%40thebrineydeep.com

您想对用户 1125 执行的任何操作都将向同一 URL 发送请求。这个想法有例外和变体，但这就是它的症结所在。

RPC 服务更像是使用一个函数库，它绑定到一个特定的 URL。您可能有一大堆相关函数都绑定到 URL /services/json。然后，如果您想更改老戴维琼斯的个人资料，您可以：

POST /services/json HTTP/1.1
Host: wherever.com
Content-type: application/json

{ "jsonrpc": "2.0",
  "id": 1,
  "method": "setProfile",
  "params": [ 1125,
    { "firstName": "Davey",
      "lastName": "Jones",
      "email": "dj@thebrineydeep.com"
    }
  ]
}

我个人更喜欢 JSON-RPC，因为：

  • 我不必尝试将我的所有函数调用都放入某种可能没有意义的资源到 URL 的映射中
  • 我们不会尝试重载 HTTP 响应代码来指示 API 错误。每个请求都会返回一个 200 响应（除非存在服务器错误），并且您可以从响应正文中知道您是否收到错误。JSON-RPC 特别擅长明确错误条件。

有时 REST 更好，因为：

  • 有时资源到 URL 的映射非常适合
  • 第三方理解更直观
  • 它提供了一个更简单的模型，仅用于检索易于识别的信息

我不认为任何一个都更容易编码。

编辑我更改了 REST 示例以使用更常见的表单编码数据而不是 JSON。当然，您可以使用 REST 指定您喜欢的任何数据格式。它不是刻在石头上的。

于 2012-10-31T22:29:31.240 回答
0

您的 REST URL 不等于您的 JSON-RPC 请求。

至少应该是http://api.example.org/getProfile?id=X

两者之间确实没有太大区别。而且您的“REST”不是真正的 REST，除非您返回的数据格式能够可靠地表达指向不同 URL 的链接，例如 XML 或 (X)HTML。在满足此要求之前，您应该只将其称为“RESTful”，因为您实际上只使用 HTTP 方法来触发内容和来回移动数据。

你使用什么并不重要——除非你知道或有使用支持你比另一个更快地构建一个或另一个解决方案的软件的经验。

于 2012-10-31T22:04:28.433 回答