什么时候JSON-RPC over http和POST比RESTful API更合适?

时间:2017-07-11 13:48:17

标签: rest api json-rpc

我目前正在与高级开发人员一起开发Web应用程序。我们已同意使用REST API进行客户端 - 服务器通信,他向我发送了参数和预期的响应。

但设计似乎并不是RESTful。相反,它看起来像JSON-RPC over http,只使用POST方法。

例如,要注册用户,请向服务器发送以下参数的POST请求。

{
  id: 1,
  method: "RegisterUser",
  params: {
    firstName: "John",
    lastName: 'Smith',
    country: 'USA',
    phone: "~",
    email: "~",
    password: "~"
  }
}

预期的回应是

{
  id: 1
  result: "jwt-token",
  error : null 
}

多个请求被发送到同一个URL,服务器根据'方法发回响应。在参数中。例如,要获取用户信息,请将{ method: "GetUserInfo", params: { id: ~ }}发送到同一网址。所有响应都具有状态代码200,并且错误由响应正文中的错误处理。因此,即使状态代码为200,如果错误不为空,则意味着错误。

我以前的做法是向用户/'发送POST请求。在注册新用户时向请求主体发送GET请求给' users / 1'检索用户信息等

当我问他为什么决定这样做时,他在上一份工作中表示,在遵循RESTful API设计时,尝试添加越来越多的API是一件痛苦的事。此外,他说他不明白为什么RESTful API在使用POST时可以使用不同的HTTP动词。

我尝试通过POST使用JSON-RPC通过http来提供REST API的优点。

  1. GET请求由浏览器缓存,但某些浏览器可能不支持POST请求缓存。

  2. 如果我们打算向外部开发人员开放API,这可能会让他们感到不适,因为这不是典型的REST API。

  3. 在什么情况下,JSON-RPC over http样式会更好地REST RESTful API?或者它只是无关紧要,只是一个优先考虑问题?

2 个答案:

答案 0 :(得分:1)

  

它看起来像JSON-RPC over http,只使用POST方法。

是的,确实如此。

  

我以前的做法是向用户/'发送POST请求。在注册新用户时向请求主体发送GET请求给' users / 1'检索用户信息等

那也不是。

里德尔。你是如何将这个问题提交给堆栈溢出的?好吧,你可能跟着你保存的书签,或者跟着谷歌的链接。也许你提交了一两个搜索,最后你点击了#34; Ask Question",它将你带到了一个表格。填写表单的详细信息后,单击“提交”按钮。这会让您了解您的问题,其中包括(除其他外)编辑问题的链接。你对此并不感兴趣,所以你已经完成了 - 除了不时刷新页面希望得到答案。

那是一个REST api 。您,代理人,跟踪从一个州到另一个州的链接,协商堆栈溢出"提交问题"协议

除了需要注意的事项之外:浏览器并不需要提前知道要发送内容的URL或要使用的http方法,因为HTML已将这些指令编码到它。浏览器只需要理解HTML标准,这样它就可以理解如何在表示中找到链接/表单。

现在,REST只是一组架构限制,可以按照Web服务器的方式进行操作。#34;。您不需要使用HTML作为媒体类型;您不需要为您的客户设计Web浏览器。但是,要做REST,你需要超媒体;和了解超媒体类型的客户 - 因此您可以更轻松地选择其中一种标准化媒体类型。

  

我是否有更多理由为什么我宁愿使用基于JSON-RPC的RESTful API而不是使用POST的http?或者它没关系?

Roy Fielding, in 2008提供了这个简单而正确的观察

  

REST适用于跨多个组织的基于网络的长期应用程序。如果您不认为需要约束,则不要使用它们。

例如,致力于GraphQL的人们认为REST约束引起的属性对于他们的用例并不具有价值;并不像能够向客户交付针对客户特定需求的表示那样有价值。

马匹课程。

答案 1 :(得分:0)

在对资源执行标准创建,读取,更新和删除操作时使用RESTful API。除非您有一些前后挂钩,否则CRUD操作对每个资源的行为应该相同。任何进入该项目的新开发人员都会很容易理解您的API,如果它符合标准。

当您执行的操作不必完全映射到任何CRUD时,请使用JSON-RPC。例如,您可能想要检索特定资源集合的计数或摘要数据。您可以使用REST执行此操作,但可能需要您将其视为某种"摘要"你读的资源。使用JSON-RPC更容易,因为您只需实现一个在数据库中运行相应查询并返回适当结果对象的过程。

或者,如果您想进行API调用,让用户删除或更新满足某些条件的资源的所有实例,而不事先知道这些实例是什么,该怎么办?

如果您需要为标准CRUD操作产生大量副作用,并且在每个操作之前或之后运行挂钩不方便,也可以使用JSON-RPC。

你不必全押其中一个,你可以同时使用它们。在适当的地方使用标准RESTful端点,并使用另一个RPC端点来处理JSON-RPC调用。