I am working on a project where I am trying to expose the function of the software. Basically I have my backend set up and was thinking of seperating the frontend from the backend code using JSON msgs. I am a little bit confused as to what is the difference between a service and an API. I know API can be build on top on services. But I have these two models in mind -- to access profile X using json-rpc
我正在研究一个项目,我试图揭示该软件的功能。基本上我有我的后端设置,并考虑使用JSON消息从后端代码中分离前端。关于服务和API之间的区别,我有点困惑。我知道API可以在服务上构建。但我想到了这两个模型 - 使用json-rpc访问配置文件X.
http://xyz.com/?request={"jsonrpc":"2.0","id":1,"method":"getProfile","params":{"id":"X"}}
http://xyz.com/?request={"jsonrpc":"2.0","id":1,"method":"getProfile","params":{"id":"X“}}
or should it be like this using REST -
或者应该是这样使用REST -
http://api.xyz.com/X
Thank You
谢谢
2 个解决方案
#1
20
"Service" vs "API" is a pretty vague question. Often, the two terms are used interchangeably. "REST" vs "RPC" is a little easier to explain.
“服务”与“API”是一个相当模糊的问题。通常,这两个术语可互换使用。 “REST”与“RPC”更容易解释。
Usually with REST, a URL represents a specific resource such as a "user", an "account", etc.. Typically, you can create/retrieve/update/delete these resources by using the HTTP methods POST/GET/PUT/DELETE. To update the profile for user 1125 you might send the following:
通常使用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
Anything you wanted to do with user 1125, you would send a request to the same URL. There are exceptions and variants of this idea, but that's the crux of it.
如果您想对用户1125做任何事情,您可以向同一个URL发送请求。这个想法有例外和变体,但这是它的关键。
RPC services is more like just using a function library, which is bound to a specific URL. You might have a whole bunch of related functions all bound to the URL /services/json
. Then if you wanted to change the profile for old Davey Jones, you would:
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"
}
]
}
I personally like JSON-RPC better because:
我个人更喜欢JSON-RPC,因为:
- I don't have to try and fit all of my function calls into some kind of resource-to-url mapping that might not make sense
- 我不必尝试将所有函数调用都放入某种可能没有意义的资源到URL映射中
- We don't try to overload the HTTP response codes to indicate API errors. Every request returns a 200 response (unless there is a server error) and you know from the response body whether you got an error or not. JSON-RPC is particularly good at being explicit about error conditions.
- 我们不会尝试重载HTTP响应代码来指示API错误。每个请求都返回200响应(除非出现服务器错误),并且您从响应正文中知道是否有错误。 JSON-RPC特别擅长明确错误条件。
Sometimes REST is better because:
有时REST更好,因为:
- Sometimes the resource-to-URL mapping fits really well
- 有时,资源到URL的映射非常适合
- It is more intuitive for third parties to understand
- 第三方更容易理解
- It offers a simpler model for just retrieving easily-identified information
- 它提供了一个更简单的模型,只需检索易于识别的信息
I don't think either one is any easier to code.
我不认为任何一个更容易编码。
Edit I changed the REST example to use the more common form-encoded data instead of JSON. But of course you can specify any data format you like with REST. It isn't carved in stone.
编辑我更改了REST示例以使用更常见的表单编码数据而不是JSON。但是,您当然可以使用REST指定您喜欢的任何数据格式。它不是刻在石头上。
#2
0
Your REST URL does not equal your JSON-RPC request.
您的REST URL不等于您的JSON-RPC请求。
At least it should be http://api.example.org/getProfile?id=X
至少它应该是http://api.example.org/getProfile?id=X
There really is not much difference between the two. And your "REST" isn't a real REST unless you return a data format that reliably can express links to different URLs, e.g. XML or (X)HTML. Until this requirement is met, you should only call it "RESTful", because you really only use HTTP methods to trigger stuff and move data back and forth.
两者之间确实没有太大区别。并且您的“REST”不是真正的REST,除非您返回可靠地表达到不同URL的链接的数据格式,例如XML或(X)HTML。在满足此要求之前,您应该只将其称为“RESTful”,因为您实际上只使用HTTP方法来触发内容并来回移动数据。
It doesn't really matter what you use - unless you know or have experience with software that supports you building one or the other solution more rapidly than the other.
使用什么并不重要 - 除非您了解或拥有支持您比另一个更快地构建一个或另一个解决方案的软件的经验。
#1
20
"Service" vs "API" is a pretty vague question. Often, the two terms are used interchangeably. "REST" vs "RPC" is a little easier to explain.
“服务”与“API”是一个相当模糊的问题。通常,这两个术语可互换使用。 “REST”与“RPC”更容易解释。
Usually with REST, a URL represents a specific resource such as a "user", an "account", etc.. Typically, you can create/retrieve/update/delete these resources by using the HTTP methods POST/GET/PUT/DELETE. To update the profile for user 1125 you might send the following:
通常使用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
Anything you wanted to do with user 1125, you would send a request to the same URL. There are exceptions and variants of this idea, but that's the crux of it.
如果您想对用户1125做任何事情,您可以向同一个URL发送请求。这个想法有例外和变体,但这是它的关键。
RPC services is more like just using a function library, which is bound to a specific URL. You might have a whole bunch of related functions all bound to the URL /services/json
. Then if you wanted to change the profile for old Davey Jones, you would:
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"
}
]
}
I personally like JSON-RPC better because:
我个人更喜欢JSON-RPC,因为:
- I don't have to try and fit all of my function calls into some kind of resource-to-url mapping that might not make sense
- 我不必尝试将所有函数调用都放入某种可能没有意义的资源到URL映射中
- We don't try to overload the HTTP response codes to indicate API errors. Every request returns a 200 response (unless there is a server error) and you know from the response body whether you got an error or not. JSON-RPC is particularly good at being explicit about error conditions.
- 我们不会尝试重载HTTP响应代码来指示API错误。每个请求都返回200响应(除非出现服务器错误),并且您从响应正文中知道是否有错误。 JSON-RPC特别擅长明确错误条件。
Sometimes REST is better because:
有时REST更好,因为:
- Sometimes the resource-to-URL mapping fits really well
- 有时,资源到URL的映射非常适合
- It is more intuitive for third parties to understand
- 第三方更容易理解
- It offers a simpler model for just retrieving easily-identified information
- 它提供了一个更简单的模型,只需检索易于识别的信息
I don't think either one is any easier to code.
我不认为任何一个更容易编码。
Edit I changed the REST example to use the more common form-encoded data instead of JSON. But of course you can specify any data format you like with REST. It isn't carved in stone.
编辑我更改了REST示例以使用更常见的表单编码数据而不是JSON。但是,您当然可以使用REST指定您喜欢的任何数据格式。它不是刻在石头上。
#2
0
Your REST URL does not equal your JSON-RPC request.
您的REST URL不等于您的JSON-RPC请求。
At least it should be http://api.example.org/getProfile?id=X
至少它应该是http://api.example.org/getProfile?id=X
There really is not much difference between the two. And your "REST" isn't a real REST unless you return a data format that reliably can express links to different URLs, e.g. XML or (X)HTML. Until this requirement is met, you should only call it "RESTful", because you really only use HTTP methods to trigger stuff and move data back and forth.
两者之间确实没有太大区别。并且您的“REST”不是真正的REST,除非您返回可靠地表达到不同URL的链接的数据格式,例如XML或(X)HTML。在满足此要求之前,您应该只将其称为“RESTful”,因为您实际上只使用HTTP方法来触发内容并来回移动数据。
It doesn't really matter what you use - unless you know or have experience with software that supports you building one or the other solution more rapidly than the other.
使用什么并不重要 - 除非您了解或拥有支持您比另一个更快地构建一个或另一个解决方案的软件的经验。