什么区别从一个类似于RPC的一个REST Web服务？ [英] What differentiates a REST web service from a RPC-like one?

问题描述

我有一个使用AJAX来从服务器抓取JSON数据的Web应用程序。它要求用户首先与他们的浏览器登录以使一个cookie可以被设置。只有 GET 和 POST 动词的使用，其中 GET 是用于检索数据和 POST 是修改数据的操作。

I have a web application that uses AJAX to grab JSON data from the server. It requires that the user first log in with their browser so that a cookie can be set. Only the GET and POST verbs are used, where GET is for retrieving data and POST is for any operation that modifies data.

据我所知，REST不同之处在于用户认证信息的上述方法是每次请求和 PUT 和发送删除动词使用。

From what I understand, REST differs from the above method in that the user authentication information is sent with every request and the PUT and DELETE verbs are used as well.

我的问题是，什么好处一个REST Web服务已经在RPC式的方法，如果终点仅仅意味着是一个用户的浏览器？我能理解REST是有利的，当客户端是未知的，但是当我只使用jQuery的Ajax调用，好处还是值得的过一个RPC样的方法？

My question is, what benefits does a REST web service have over the RPC-like method, if the end point is only meant to be a user's browser? I can understand how REST is beneficial when the client is unknown, but when I'm only using jQuery ajax calls, are the benefits still worth it over an RPC-like method?

推荐答案

一个REST和RPC之间的巨大差异是，其余的都是对资源和RPC更多的是行动。例如，对于一个真正的RESTful服务，你绝不会调用类似 http://domain.com/service/User/jason/添加或<一href="http://domain.com/service/User/addUser?username=jason">http://domain.com/service/User/addUser?username=jason.通过RESTful服务，你永远只能引用资源的URL，然后定义如何处理使用HTTP动词和请求的主体的资源。因此，一个GET请求到http：/domain.com/service/jason应该返回有关资源（杰森用户）的信息。你可以得到更具体的说 http://domain.com/service/user/jason 但结果应该是相同。如果你添加一个名为杰森用户则可以使用完全相同的网址 http://domain.com/service/user/jason，但你会使用PUT动词和请求的主体将包含额外的数据。要删除杰森资源，您会再次使用完全相同的网址（http://domain.com/service/user/jason），并使用DELETE动词。要更新您将使用POST谓词。

One of the big differences between REST and RPC is that REST is all about resources, and RPC is more about actions. For example, with a truly RESTful service you would never call something like http://domain.com/service/User/jason/add or http://domain.com/service/User/addUser?username=jason. With RESTful service you only ever reference the resource in the URL and then you define what to do with that resource using HTTP verbs and the body of the request. So a GET request to http:/domain.com/service/jason should return information about the resource (the jason user). You could get more specific and say http://domain.com/service/user/jason but the result should be the same. If you were adding a user named jason you would use the exact same URL http://domain.com/service/user/jason but you would use the PUT verb and the body of the request would contain additional data. To delete the jason resource you would, again, use the exact same URL (http://domain.com/service/user/jason) and use the DELETE verb. To update you would use the POST verb.

REST是伟大的，你打算让其他开发者使用的面向公众的API。它们可以被制成非常标准的，以便它们不要求一吨的preexisting知识使用的服务。没有WSDL调用因为无国籍就可以了，等也使得他们在部分网络故障更加稳定。

REST is great for public-facing APIs that you intend for other developers to use. They can be made to be very standard so that they don't require a ton of preexisting knowledge about the service to use. No WSDL calls, etc. Because of the statelessness it can also makes them more stable during partial network failures.

从你描述的，我不认为你需要一个真正的RESTful服务。但是，你可能要考虑，展望未来，如果你会需要一个更标准的API。我做的，我只用于内部使用的项目REST服务，但那是因为我打算来访问，可能还有许多其他的服务，并在未来可能从其他开发商的服务。因此，即使一开始我只是用它的一对夫妇的项目，最终目标需要更多的标准接口。

From what you are describing, I do not think you need a truly RESTful service. But you might want to consider, going forward, if you would ever need a more standard API. I made a REST service for a project that I only use for internal use, but that is because I intended to access that service from, potentially, dozens of other service, and in the future possibly from other developers. So even though at first I was only using it for a couple projects, the ultimate goal required a more standard interface.

这篇关于什么区别从一个类似于RPC的一个REST Web服务？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！