REST Web 服务与类似 RPC 的服务有何不同？
我有一个使用 AJAX 从服务器获取 JSON 数据的 Web 应用程序。它要求用户首先使用浏览器登录，以便设置 cookie。仅使用 GET 和 POST 动词，其中 GET 用于检索数据，POST 用于任何以下操作：修改数据。
据我了解，REST 与上述方法的不同之处在于，用户身份验证信息是随每个请求一起发送的，并且 PUT 和 DELETE 动词是也用过。
我的问题是，如果端点仅是用户的浏览器，那么 REST Web 服务相对于类似 RPC 的方法有什么好处？我可以理解当客户端未知时 REST 有什么好处，但是当我只使用 jQuery ajax 调用时，与类似 RPC 的方法相比，这些好处是否仍然值得？
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.
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.
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
REST 和 RPC 之间的一大区别是，REST 更关注资源，而 RPC 更关注操作。例如，对于真正的 RESTful 服务，您永远不会调用类似 http://domain.com/service 的内容/User/jason/add 或 http://domain.com/service/用户/addUser?用户名=jason。使用 RESTful 服务，您只需引用 URL 中的资源，然后使用 HTTP 动词和请求正文定义如何处理该资源。因此，对 http://domain.com/service/jason 的 GET 请求应返回有关资源（jason 用户）的信息。您可以更具体地说 http://domain.com/service/user/jason 但是结果应该是一样的。如果您要添加名为 jason 的用户，您将使用完全相同的 URL http://domain.com/service/ user/jason 但您将使用 PUT 动词，并且请求正文将包含其他数据。要删除 jason 资源，您将再次使用完全相同的 URL (http://domain.com/service /user/jason）并使用 DELETE 动词。要更新，您可以使用 POST 动词。
REST 非常适合您打算供其他开发人员使用的面向公众的 API。它们可以变得非常标准，这样就不需要大量关于要使用的服务的预先存在的知识。没有 WSDL 调用等。由于无状态，它还可以使它们在部分网络故障期间更加稳定。
根据您的描述，我认为您不需要真正的 RESTful 服务。但您可能需要考虑，未来是否需要更标准的 API。我为一个仅用于内部使用的项目创建了一个 REST 服务，但这是因为我打算从潜在的数十个其他服务以及将来可能从其他开发人员访问该服务。因此，尽管一开始我只将它用于几个项目，但最终目标需要一个更标准的接口。
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 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.
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.
可以这样想——重要的是功能，还是所执行的信息？
当您处理 REST 时，您正在处理信息状态 - 您查看当前信息是什么 (GET)，或者更改特定文档（POST、DELETE），或者创建新文档（放）。
对于 RPC，它是关于过程/函数/方法/操作...无论您用您的语言如何称呼它们。这些信息只是对服务进行操作或从服务返回的信息……但它可能是众多信息之一。我们可能正在搜索并返回项目列表。或者我们可能正在谈判一些需要来回互动的事情。 （REST 的协商大部分是通过 HTTP 处理的，因此您必须使用 Accept 和 Accept-Language 标头进行操作）但更重要的是操作。
然后是第三种类型，即文档/文字 SOAP ...其中重要的是消息，您必须根据消息猜测所调用的函数是什么。如果您只是处理 CRUD 操作，这可能没问题。在这种情况下，相对于 REST 的优点是您仍然可以拥有 WSDL，因此您可以提前知道要发送的必要元素以及期望返回的内容。
它们都有效……主要是关于您如何看待问题，以及将您已有的内容转换为 API 的难易程度。如果您从头开始，您可能可以做任何您想做的事情。我个人喜欢 SOAP（无论是 document/lit 还是 RPC），因为我可以提供一个 WSDL 文件，人们可以用它来引导他们的客户端。我遇到过人们在几个小时内进行严肃查询的情况。 （解释 API 的一些抽象微妙之处，例如发送空字符串与 null 之间的区别需要一些时间，但我在 REST 中也会遇到同样的问题）
Think of it this way -- is it the function that matters, or the information that's being acted on?
When you're dealing with REST, you're deaing with a state of information -- you look to see what the current information is (GET), or you change that specific document (POST, DELETE), or you create a new document (PUT).
With RPC, it's about the procedures / function / methods / operations ... whatever you call them in your language. The information is just something that gets operated on or returned from a service ... but it might be one of many. We might be searching, and returning a list of items. Or we might be negotiating something where we need some interaction back and forth. (REST's negotiation for the most part is handled through HTTP, so you have to do things with Accept and Accept-Language header) But it's the operation that's more important.
Then there's the third type, which is document/literal SOAP ... where it's the message that's important, and you have to guess what the function being called is based on the message. If you're just dealing with CRUD operations, this is probably okay. The advantages over REST in this case is that you can still have a WSDL, so you know in advance what the necessary elements are to send, and what to expect in return.
They all work ... it's mostly about how you think about the problem, and how easy it is to convert from what you already have to expose it as an API. If you're starting from the ground up, you can likely do whatever you want. I personally like SOAP (either document/lit or RPC) in that I can give a WSDL file that someone can use to bootstrap their client. I've had cases where people were doing serious queries within a couple of hours. (explaining some of the abstract subtleties of the API, such as the difference between sending an empty string vs. a null took some time, but I would've had the same issues w/ REST)
REST 最好的描述是与资源一起工作，而 RPC 更多的是关于操作。
REST：
代表代表性状态转移。这是组织独立系统之间交互的一种简单方法。
RESTful 应用程序使用 HTTP 请求来发布数据（创建和/或更新）、读取数据（例如，进行查询）和删除数据。因此，REST 使用 HTTP 来执行所有四个 CRUD（创建/读取/更新/删除）操作。
RPC：
RPC 基本上用于跨不同模块进行通信以服务用户请求。
例如，在 openstack 中，例如 nova、glance 和 neutron 在启动虚拟机时如何协同工作。
作为一种编程方法，REST 是 Web 服务和 RPC 的轻量级替代方案。
与 Web 服务非常相似，REST 服务是：
REST is best described to work with the resources, where as RPC is more about the actions.
REST:
stands for Representational State Transfer. It is a simple way to organize interactions between independent systems.
RESTful applications use HTTP requests to post data (create and/or update), read data (e.g., make queries), and delete data. Thus, REST uses HTTP for all four CRUD (Create/Read/Update/Delete) operations.
RPC:
RPC is basically used to communicate across the different modules to serve user requests.
e.g. In openstack like how nova, glance and neutron work together when booting a virtual machine.
As a programming approach, REST is a lightweight alternative to Web Services and RPC.
Much like Web Services, a REST service is:
您关于 REST 与调用对象的耦合程度较低的说法是正确的 - 如果您与需要从服务器调用 WSDL 文件的 SOAP Web 服务进行比较，那么 REST Web 服务的耦合程度较低（即不需要了解Web 服务之前调用它）。大多数时候，需要将令牌与给定“表示”的请求一起传递。
我不认为使用 ajax 中的 REST 有很大的好处，事实上，根据您正在处理的 API，您可能需要一个在使用基于 SOAP 的 Web 时作为 URI 参数（查询字符串参数）传入的令牌服务，这个没必要。实际上，将 SOAP Web 服务与 ajax 调用相结合、以 JSON 格式传递数据并将 JSON 反序列化为服务器端的对象非常容易。最重要的是，jQuery 使这一切变得超级简单。
You are correct about REST being less coupled to the calling object - if you are comparing to a SOAP web service that requires a WSDL file to be called from the server, than yes, REST web services are less coupled (ie require no knowledge of the web service prior to calling it). And most of the time a token needs to be passed along with request for a given 'representation'.
I don't think there is a huge benefit by using REST from ajax, in fact, depending on the API you are dealing with, you may require a token which is passed in as URI parameter (querystring parameter) while using a SOAP based web service, this is not necessary. It is actually quite easy to combine SOAP web services with ajax calls, pass your data in JSON format and deserialize the JSON into an object on the server side. And to top it off, jQuery makes all of this super-easy.
不想把它告诉你们所有人。
RPC 正在进行本地调用，抽象底层远程
行为。你猜怎么着？做 REST 是同样的事情。
关于 REST 的争论是关于资源的，这是不正确的，你实际上
直接调用动作。
我声称 REST over HTTP with jsons 是 RPC 的一种形式。
例如，其他流行的 RPC 可能包括 SOAP
hate to break it to you all.
RPC is making a local call, that abstracts the underlaying remote
behaviour. and guess what? doing REST is the same thing.
the argument about REST is about resources is incorrect, you actually
directly invoke actions.
I claim REST over HTTP with jsons are a form of RPC.
other popular RPC may include SOAP for example
RPC 和 REST 只是不同的方法，各有优缺点，而且两者的价值取决于上下文。您甚至可以将这两种方法混合在一个 API 中。
上下文，这是关键。没有万能的解决方案，不要盲目跟风，一定要结合上下文思考，在选择解决方案时一定要务实。
了解更多 这里！
RPC and REST are only different approaches with pros and cons and both are valueable depending on the context. You can even mix these two approaches in a single API.
The context, that’s the key. There are no panacea solution, don’t follow fashion blindly, you always have to think within a context and must be pragmatic when choosing a solution.
Learn More here!.