web-services - 最佳 SOAP/REST/RPC Web API 的示例？你为什么喜欢他们？他们有什么问题？

Question

就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、引用资料或专业知识的支持，但这个问题可能会引发辩论、争论、投票或扩展讨论。如果您觉得这个问题可以改进并可能重新打开，visit the help center寻求指导。




10年前关闭。




在我的公司，我们开始涉足 Web API 以访问和更新我们的数据；最初是为合作伙伴提供的，但将来可能会向公众提供。目前 API 的外观(例如 SOAP、REST、RPC)是完全开放的，我们还没有做出任何决定，所以我对人们认为好的 Web API 的两个示例以及您认为的原因很感兴趣那。

我感兴趣的是来自使用不同语言的人的意见(我们可能会向使用多种平台的人提供 API，特别是包括 .NET、Java、ActionScript 和 JavaScript)关于您认为好的 Web API例子，你有很好的经验。

我想介绍的几点:

你更喜欢 SOAP 类型的服务还是 REST/RPC 风格的服务？我怀疑有平台支持(例如 .NET、Java)的人会更喜欢 SOAP，而使用没有平台支持的语言的人会更喜欢其他人，但我想验证这个假设。

您是否关心 API 是否实际上是 RESTful 或是否是普通的旧 RPC 样式 HTTP GET/POST？如果是这样，你为什么在乎？一个 API 正确地描述自己(即，如果它是 RPC 风格，就不要声称它是 RESTful)比它实际上是否是两者之一更重要吗？

我们需要验证谁在使用该服务。我一直在研究 Amazon S3 身份验证，它使用公共(public)标识符和私有(private) token ，用于将请求的参数散列为验证 token (这也类似于 flickr)。您以前是否使用过这种类型的身份验证，您是如何使用它的？您是否发现有任何哈希算法存在问题(即您的平台不支持)？您希望在 HTTP header 中还是在 URI 中发送散列？

应该如何处理版本控制？拥有/v1/ 是个好主意吗？键入子目录，以便可以在旁边添加 future 的版本，或者您会做一些不同的事情，比如在请求有效负载或查询中使用版本？您希望支持您构建的 API 版本多长时间(即，如果引入 v2，您对 v1 生命周期的期望是多少)。

此外，任何其他意见和要点都会很有用。

我故意对我们正在实现的 API 的实际类型保持模糊，因为我正在寻找关于人们认为好的 API 和实现机制的一般指导，所以这篇文章及其答案将对更多人有用在将来。

注意:我已经搜索并找不到关于此的通用问题 - 它们似乎都特定于某种类型的 API - 但如果它是重复的，请告诉我。另外，如果它应该是社区 wiki(我认为人们应该得到答案，所以我没有做到这一点)，那么请告诉我，我会改变它。

Answer 1

这是我的看法。

尽管从 Java 的角度来看，我实际上更喜欢 REST。具有多个 namespace 的 SOAP 信封及其复杂的结构令人厌恶。它试图解决大多数想象中的问题，但不能有效地解决任何问题。我发现 SOAP 唯一有用的是它具有授权和错误标准。另一方面，通过在根 XML 元素中包含四个标准属性(用户名、密码、errorCode、errorDescription)可以更轻松地解决这两个问题。

好的 API 描述和文档确实是最重要的。成熟框架中 REST 和 SOAP 的区别主要在于几行配置。

对于 SOAP，发送散列作为 SOAP 安全性的一部分；对于 REST，我喜欢将所有内容打包在有效负载中，并避免使用 HTTP header 进行身份验证。不过我只有主观原因，因为我不得不与那些不容易暴露 HTTP header 的框架作斗争。

我个人的偏好是为不同的协议(protocol)版本使用不同的 URI。根据我的经验，这为您在较新版本中提供了更大的灵 active ，并且连接到不受支持的协议(protocol)版本的旧客户端由于明显的原因而立即停止工作。此外，有时您可以将旧版本的应用程序映射到旧的 URI，以避免在新的服务器版本中有旧的支持代码。至于您支持旧版本的协议(protocol)多长时间......理想情况下，只要您有使用它的客户端。这比技术决策更重要。您应该至少支持一个以前的协议(protocol)版本。将客户推向新版本以降低遗留支持成本通常符合您的利益；从客户端来看，新版本应该意味着新功能、更好的协议(protocol)和某种额外的业务激励(如果仅新功能还不够的话)。