logo标签列表

最佳SOAP/REST/RPC web API的例子？你为什么喜欢它们？它们有什么问题？

web-servicesrestsoaprpc
48
在我们公司，我们开始涉足Web API以访问和更新我们的数据，最初是为了合作伙伴，但未来可能向公众开放。目前API的形式（例如SOAP，REST，RPC）完全开放，我们还没有做任何决定，因此我对人们认为好的Web API示例以及您认为为什么感兴趣。
我感兴趣的是不同语言用户（我们可能会向使用多种平台的人提供API，特别是包括 .NET、Java、ActionScript 和 JavaScript 的人）对您认为好的Web API示例的意见以及您的良好体验。
一些要点如下： 1. 您更喜欢SOAP类型的服务还是REST/RPC样式的服务？我怀疑具有平台支持（例如.NET，Java）的人会更喜欢SOAP，而使用没有平台支持的语言的人则更喜欢其他服务，但我想验证这个假设。 2. 您是否关心API实际上是RESTful还是一个普通的RPC样式的HTTP GET/POST？如果是，为什么关心？一个API是否正确描述自己更重要（即不要声称自己是RESTful而实际上是RPC样式），而不是它实际上是两者之一？ 3. 我们需要验证谁在使用服务。我一直在研究Amazon S3身份验证，它使用公共标识符和一个私有令牌来将请求的参数散列成验证令牌（这也类似于flickr）。您以前使用过这种身份验证吗？您如何处理它？有没有哈希算法您认为有问题（即不受您所使用平台支持）？您更喜欢在HTTP头中发送哈希还是在URI中？

  • 版本控制应该如何处理？设置类似于 /v1/ 的子目录以便未来可以添加新版本是否是一个好主意，或者您会采取不同的方式，比如将版本放在请求有效负载或查询中？您期望构建API的版本能够得到支持多长时间（即如果引入了v2，那么v1的生命周期预期是多少）。

    • 此外，任何其他观点和需要覆盖的内容都将很有用。

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

    注意：我已经进行了搜索，但找不到与此相关的通用问题-它们似乎都针对某种类型的API-但如果它是重复的，请告诉我。另外，如果它应该是社区维基（我认为人们应该得到回答的信用，所以我没有将其设为社区维基），请让我知道，我会将其更改为社区维基。

    3
    你更喜欢SOAP/RPC类型服务还是REST样式的服务？SOAP是RPC概念应用于XML-over-HTTP的一个例子，而REST则是一个更加微妙的概念。 - U62
    2
    真的不明白这篇帖子有什么不建设性的地方。事实上，对我来说今天非常有用。这个帖子不应该被关闭。 - black sensei
    8个回答
    19

    以下是我的看法。

    1. 虽然我来自Java的角度，但我更喜欢REST。SOAP信封具有多个命名空间和复杂的结构，很让人不爽。它试图解决大多数是想象中的问题，并且没有有效地解决实际问题。我在SOAP中发现有用的唯一事情是它对授权和错误有标准。另一方面，这两个问题可以通过在根XML元素中包含四个标准属性（用户名、密码、错误代码、错误描述）更容易地解决。

    2. 良好的API描述和文档确实是最重要的。成熟框架中REST和SOAP之间的区别主要在于少量配置代码。

    3. 对于SOAP，将哈希作为SOAP安全性的一部分发送；对于REST，我喜欢将所有内容打包到载荷中，并避免使用HTTP头进行身份验证。不过这些只是我的个人偏好，因为我曾经与不容易公开HTTP头的框架进行过斗争。

    4. 我个人倾向于为不同的协议版本设置不同的URI。根据我的经验，这会在新版本中给您带来更多灵活性，而连接到不受支持的协议版本的旧客户端会立即停止工作，原因显而易见。此外，有时您可以将应用程序的旧版本映射到旧URI，以避免在新服务器版本中具有遗留支持代码。

      至于要支持多长时间的旧协议版本……理想情况下，只要您有使用它的客户端。这是一个更商业化的而不是技术性的决定。您应该支持至少一个先前的协议版本。通常，推动客户端向新版本转移以降低遗留支持成本对您来说是划算的；从客户端的角度来看，新版本应该意味着新功能、更好的协议和某种形式的额外商业激励（如果仅凭新功能不足够）。

    8
    HTTP有关于身份验证（Authenticate头）和错误（5XX响应）的"标准”。将身份验证信息放在有效载荷中通常是一个不好的主意，因为它会破坏可能缓存或处理它们的中介，并且它防止身份验证方案被跨站点重用。当你违反机遇巧合原则时，也会违反REST原则。 - SerialSeb
    在几天后就要进入2014年了。Google不再展示SOAP搜索API了...https://developers.google.com/soap-search/ 实际上，这个决定是在上面的帖子发布之前3年就已经做出的。 - user182669
    9
    5
    请问您能将其变成一个实际的链接吗？ - JB.
    3
    我会看看亚马逊正在做什么-http://aws.amazon.com/-这些赚钱的家伙显然已经从中学到了更多的经验教训。
    其他API我会关注-salesforce.com和微软的CRM API也非常有趣。Twitter也拥有一个经过实战考验的REST API。
    2
    我认为亚马逊之所以盈利并不是因为他们的API，而是因为他们其他的服务。仅仅因为一个大公司采用了某种编码方法，并不意味着它是最好的，甚至可能只是随意选择。我们并不知道他们是否做过功课。 - user19302
    2
    我从相反的角度来看待这个问题。他们选择了最适合工作的最佳工具/方法，因为他们必须用它来销售产品/服务。他们经历了迭代，支持了客户。他们看到了一些书本上的想法还没有涉及到的缺陷。 - dfasdljkhfaskldjhfasklhf
    1
    亚马逊的API实际上不是REST，而只是RPC。 - aehlke
    3
    RPC方法也是一个不错的选择。它减少了开销，像Ice、Google Protocol Buffers和Apache Thrift这样的项目使得基于RPC的服务更易于开发。
    如果您不需要提供基于Web的API，则RPC也可以是您想要探索的一种选择。
    2
    另一个与此相关的事情是易用性：1）人们更容易理解RPC方法而不是rest方法；2）实现起来更容易（“这是一个函数及其参数和返回值”）。 - Richard Levasseur
    1

    在我看来，这完全取决于你提供的应用程序类型。如果你正在进行重要的大额交易，那么一定要选择SOAP（正如他们所说的WS“死星”）。但是，如果你提供的是社交应用程序，则应选择REST，因为它更简单，更适合公共黑客攻击。

    1

    如果正确地实现，REST 很容易理解（模型化 HTTP），直接（面向资源）并且可以被几乎所有编程语言解析（XML）。

    2
    REST不一定是HTTP，它是协议无关的。 - aehlke
    0

    如果你最终无法做出决定，那么你可以实现它们全部。在这种情况下，查看其他人的做法是很有用的。我建议你使用开源XML本地数据库eXist，它提供了你正在研究的三种接口。

    网页内容由stack overflow 提供, 点击上面的
    可以查看英文原文，
    原文链接