XML-RPC 是否不好用作公共 API 实现的协议？
我需要为我这段时间正在进行的一个项目实现一个Web API。我读到有很多标准协议可以做到这一点：XML-RPC、SOAP、REST。显然，据我所知，XML-RPC 是最容易实现和使用的，但我没有找到任何有关使用它来实现 API 的信息。相反，我发现了许多关于在 PHP 中创建 REST API 的教程。使用 XML-RPC 实现公共 Web API 是否有任何反迹象？
另外，更一般地说，我可以（某种程度上）为我的 API 定义一个自定义协议，以使事情变得更简单（即只接受包含我需要的参数的 GET 请求）：这会那么糟糕吗？使用标准协议是必须做的吗？
I need to implement a web API for a project I'm working on in this period. I read there are many standard protocols to do it: XML-RPC, SOAP, REST. Apparently, the XML-RPC one is the easiest one to implement and use from what I saw, but I didn't find anything about using it to implement an API. Instead I found many tutorial about creating a REST API in PHP, for example. Is there any counter-indication for using XML-RPC to implement a public web API?
Also, more generally speaking, I could (sort of) define a custom protocol for my API, to keep things simpler (i.e. accepting only GET request containing the parameters I need): would this be so bad? Is using a standard protocol a must-do?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
如果你的应用程序非常简单，那么简单地使用 GET 请求并传入参数并没有什么问题。您不必使用诸如 SOAP 之类的标准。
从技术上讲，如果您发送的是实体，您将使用 REST。例如，如果您有想要传输的域对象，那么可以通过 GET 检索这些对象，并通过 PUT 更新这些对象，所有这些都通过标准 URL。尽管许多人将上述第一种选择称为休息，但这并不完全正确。
SOAP/XML-RPC 是拥有适用于所有平台的库的协议，但由于其 XML 膨胀和（相对）复杂的模式而正在慢慢消亡。我不太喜欢这些协议，而且它们从未得到如此广泛的使用。人们可能会反驳，但尝试找到一家使用其公共协议的大型网络公司，我会给那个人买一个三明治。
看来 JSON 现在正在统治世界。它结构紧凑，解析速度快，非常适合 Web 应用程序，因为您可以将其直接通过管道传输到 JavaScript 中。只需使用返回 JSON 的 HTTP GET，您就可以获得很大的帮助。
If your app is a very simple one, then there is nothing wrong with simply using GET requests and passing in parameters. You don't have to use some standard like SOAP.
Technically you would use REST if what you are sending is entities. For example if you have domain objects which you want to transport, then these can be retrieved via a GET, updated via PUT all through a standard URL. Although many people refer to the first option above as rest, that is not entirely right.
SOAP/XML-RPC are protocols that have libraries for every platform under the sun but are slowly dying due to their XML bloat and (relatively) complex schema. I am not a big fan of these protocols and they have never been that widely used. People may argue otherwise, but try and find a large web company that uses either for their public protocol and I'll buy that person a sandwich.
Seems that JSON is taking over the world now. It's compact, fast to parse, and ideal for web apps as you can pipe it straight into javascript. You can get very far simply using a HTTP GET that returns JSON.
为什么不直接使用 SOAP，因为它在许多平台上更容易实现。
也许如果您使用的平台不支持 SOAP，那么使用 XML-RPC 可能会更容易。但是，大多数平台不支持 XML-RPC。
SOAP 协议基于 XML-RPC，这大大降低了 XML-RPC 的用处。
Why not just use SOAP, which is a lot easier to implement on many platforms.
Maybe if you're using a platform with no support for SOAP, then it might be easier to use XML-RPC. But then, most platforms do not have XML-RPC support.
The SOAP protocol was based on XML-RPC, which pretty much made XML-RPC much less useful.
为了回答你的问题，我认为 SOAP 或 RESTful API 是最好的实现方式，因为你的 API 的使用者可能对它们有更多的经验。
此外，最后一点，您谈到接受具有特定参数的 get 请求，这是设计 RESTful API 的一个非常重要的部分。如果您认为这很容易实现，我强烈鼓励您对用您选择的语言构建 RESTful API 进行一些研究，因为我认为您会发现它非常接近您提出的替代解决方案。
To answer your question, I think SOAP or RESTful API would be the best to implement as consumers of your API would likely have more experience with them.
Additionally, your last bit, where you talk about accepting get requests with specific parameters, that is a very large part of designing a RESTful API. If you think that would be easy to implement, I strongly encourage you to do some research on building a RESTful API in your language of choice, because I think you will find it very close to the alternate solution that you proposed.
我们的应用程序提供所有三种协议
根据我们的经验，初学者或面向资源的用户正在使用纯 HTTP。有些（不是很多）选择使用 XML RPC。大多数情况下，当他们刚接触该主题并且没有太多服务 API 时。高端用户和技术爱好者都选择 SOAP。
我认为 XML-RPC 的时代已经结束了。要么选择纯 HTTP POST（如果您能够定义干净的服务签名，我更喜欢这种方式，好的候选者是只有原始类型，没有真正意义上的对象的签名），要么选择 SOAP（如果您不受资源限制）。
我什至更喜欢“较新”的方法，例如 JSON RPC，而不是 XML RPC。如果您需要的不仅仅是简单的原始参数签名，JSON 可能是一个不错的选择。
Our application provides all three protocols
From our experience a beginner or resource oriented user is using plain HTTP. Some (not many) opted to use XML RPC. Mostly when they are new to the topic and do not have many service API's around. High end users and technology loving ones go for SOAP.
Me i think days of XML-RPC are over. Either go for plain HTTP POST (which i prefer if you're able to define a clean service signature, good candidates are ones that only have primitive types, no real sense of objects) or choose SOAP if you are not resource restricted.
I'd prefer even "newer" ones like JSON RPC over XML RPC. JSON may be a good choice if you need more then plain primitive parameter signatures.
缺点是，当您可以使用已经存在的操作时，您将定义自己的资源操作语义（您的客户端开发人员需要学习）。
HTTP 定义了可以使用的操作/动作/动词。如果你使用这个，你可以提供一个统一的接口，api用户可以调用，而不必被迫学习你的新计划。
这样做可以让您实现 REST 中有用的约束之一。
The downsides would be that you will be defining your own semantics for operating on resources (which your client developers will need to learn) when you could use the operations that already exist.
HTTP defines the operations/actions/verbs that can be used. If you use this, you can provide a uniform interface that api users can call without being forced to learn your new plans.
Doing so would allow you to achieve one of the helpful constraints in REST.
出色地。我必须为一家公司制作一个 magento android 应用程序，并且在 SOAP、REST 和 XML-RPC 三种之间感到困惑，最终选择了 XML RPC - 真的很棒而且简单：D
Well. I had to make a magento android app for a company , and was confused between the three SOAP , REST and XML- RPC , eventually went with XML RPC - really awesome and simple :D