2012-10-31 86 views
6

我正在一个项目中尝试公开该软件的功能。基本上我有我的后端设置,并正在考虑使用JSON消息从后端代码分离前端。对于服务和API之间的区别,我有点困惑。我知道API可以建立在服务之上。但我有这两种模式 - 访问配置文件X使用json-rpcWeb服务 - REST vs PHP JSON RPC

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

或者它应该是这样使用REST -

http://api.xyz.com/X

谢谢

+1

在这里你有一个比较http://stackoverflow.com/questions/1098473/rest-vs-rpc – Chuidiang

+0

如果你想RPC使用SOAP。否则REST。 –

回答

20

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

通常使用REST,URL表示特定资源,例如“用户”,“帐户”等。通常,您可以使用HTTP方法POST/GET创建/检索/更新/删除这些资源/ PUT/DELETE。要更新用户1125配置文件,你可以发送以下:你想与用户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 

任何事情,你会发送到同一个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": "[email protected]" 
    } 
    ] 
} 

我个人很喜欢JSON-RPC更好,因为:

  • 我没有尝试适合所有的我函数调用某种资源到URL映射可能没有意义
  • 我们不尝试重载HTTP响应代码以指示API错误。每个请求都会返回一个200响应(除非存在服务器错误),并且您从响应主体了解您是否遇到错误。 JSON-RPC特别擅长明确错误条件。

有时REST是更好,因为:

  • 有时资源到URL映射配合得很好
  • 更直观的第三方理解
  • 它提供了一个简单的模型只是检索容易识别的信息

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

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

+0

感谢您的回复..在rpc服务周围创建一个“REST包装器”是否有意义...如果您正在访问用户配置文件“user1”,那么用户将键入 - “http://xyz.com/user1“..这会在内部调用rpc-service来获取id为”user1“的资源? – Fox

+0

这是可行的,只要你有一个从REST <-> RPC的简单映射。即便如此,这是额外的工作。你必须问自己,你必须从中获得什么。我通常会只用一个或另一个去。 – slashingweapon

0

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

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

真的是没有两者太大的差别。除非您返回的数据格式可以可靠地表示指向不同网址的链接,例如,您的“REST”不是真正的REST。 XML或(X)HTML。在满足这个要求之前,你只能称它为“RESTful”,因为你实际上只使用HTTP方法来触发内容并来回移动数据。

使用什么并不重要 - 除非您知道或有使用软件的经验,可以帮助您更快速地构建其中一种或另一种解决方案。