我一直在构建使用 Saleforce SOAP API 的控制台应用程序,现在需要在 Web 应用程序中使用 Salesforce API。
我是否正确假设 SOAP 更适合非基于 Web 的应用程序,而 REST 更适合 Web 应用程序?
如果我在哪里创建将用于从本地应用程序报告或从我们的网站发布到销售人员的包装器,我是否应该同时公开 REST 和 SOAP api,这取决于应用程序是什么?还是我应该坚持使用一个?如果我只需要选择一个,我应该考虑哪些决定因素?
我一直在构建使用 Saleforce SOAP API 的控制台应用程序,现在需要在 Web 应用程序中使用 Salesforce API。
我是否正确假设 SOAP 更适合非基于 Web 的应用程序,而 REST 更适合 Web 应用程序?
如果我在哪里创建将用于从本地应用程序报告或从我们的网站发布到销售人员的包装器,我是否应该同时公开 REST 和 SOAP api,这取决于应用程序是什么?还是我应该坚持使用一个?如果我只需要选择一个,我应该考虑哪些决定因素?
其他答案包含一些很好的一般信息,一些销售人员需要考虑的具体事项是
1) 您可以直接在 SOAP API 中批量更新数据,但您需要使用 Async Bulk API 从 REST 中执行此操作。
2)soap API 包含一些 REST API 中没有的东西,最显着的是 describeLayout、queryAll、getDeleted 和 getUpdated
3) REST API 包含一些 SOAP API 中没有的东西,包括用于 chatter 的 API,以及对最近访问记录列表的访问。
4) REST API 可以访问二进制数据(文件、附件、内容等),而无需 base64 编码/解码的开销。
因此,取决于您的应用程序正在尝试做什么,可能会以一种或另一种方式推动您。
我相信,如果您通过 .NET 应用程序使用它,无论它是否是 Web 应用程序,它最终都是个人偏好。
就个人而言,我会选择 SOAP,因为 .NET 有很多内置功能可以使用 SOAP 服务,它为您构建所有方法原型,并且比您自己手工制作 REST 请求更快。.NET 将负责 SOAP 的编组。
至于构建包装器,您必须考虑您的目标受众,如果您的目标受众是其他 .NET 应用程序开发人员,那么公开您自己的 WCF 服务可能是一个不错的选择,WCF 还具有用于 SOAP 或 REST 的端点。
恕我直言,如果您的问题表明您正在从 .NET 开发解决方案,那么 SOAP 是可行的方法。REST 服务是有益的,因为它们缺乏围绕 SOAP 的大量和工具集要求,并且对于没有访问像 .NET 之类的大量投资工具的引导开发人员来说非常有用。我同意其他评论,即 REST 更接近地反映了底层 HTTP 方法,并且更易于明确地阅读和解析,但这并不是您在 VS 和 .NET 等工具中真正需要关心的事情。
此外,由于您现有的控制台应用程序可能会在某些时候被引入到通信组合中,因此最好让 WCF 灵活地与传输无关,而不是像使用 REST 那样绑定到 HTTP。
所以我真的不认为您能够利用 REST 的优势或受到 SOAP 的缺点的影响,因此使用最适合您现有工具集的高度标准化的选项是有意义的。
当两者都可用时使用 REST 或 SOAP 的决定通常与:
如果“本地”应用程序从服务器端调用服务,那么在其他条件相同的情况下,您至少可以直接从 WSDL 生成 C# 代码,这使得使用 SOAP API 更简单(无需手动编码)。
如果 Web 应用程序需要直接从客户端(浏览器)调用 API,则使用 REST 并使用 JSON。这会简单得多。无论如何,您将无法重用相同的包装器,因此使用两个不同的 API 没有问题,除了学习它们所花费的时间。
如果 API 的 Web 应用程序使用在服务器端(而不是客户端),那么肯定只针对单个 API。如果您想自动生成代码来调用它,则使用 WSDL,否则为简单和高效,请使用 REST。
IMO,SOAP 是作为合同类型消息传递架构师创建的标准,即在传递消息时只使用这个“合同”。它足够通用,不包含任何特定技术。
REST 是一种包含 HTTP 的实际方法,它是一种最大限度地利用 GET、POST、PUT 和 DELETE 的方法。
我不会假设一个比另一个更好,它真正归结为使用正确的工具来完成这项工作。我不会区分基于网络的应用程序和非基于网络的应用程序。因为 SOAP 或 REST 对两者都有好处。
这里有几个问题我会首先得到回答:
1)谁是我的目标客户。Microsoft Workshop 客户端,Java,PHP 类型。
2)我想向我的 Api 公开什么类型的(缺乏更好的术语。)“端点”。(JSON、XML、Ajax、POX 或以上所有。)
3) 我的客户将使用此 API 做什么?他们是否已经拥有基于 SOAP 的客户端。如果是这样,SOAP 就是要走的路。
4) REST 将使您考虑您的 URL 设计,从而允许客户端“混搭”数据以构建他们需要的内容。所以,如果你认为这是你想要的。REST 是要走的路。
5) REST 利用 HTTP 中的“GET”,这允许客户端缓存结果。“所谓的条件GET。它允许他们缓存一个大对象,仅通过一个标头(小)询问服务器最后一次更新是否与缓存的内容匹配,如果是的话。不要打扰完整的对象GET,什么缓存的是最新版本。这可以在 SOAP 中完成,但开箱即用,REST 对此更好。
无论如何,希望这能给您提供更好的数据,以便您做出更好的决定。如果一切都失败了,你可以两者都做。但是,您将不得不尝试获得两种类型的服务(不同的方法)和一个代码库。(可能很棘手,但没那么难。)
亲自。我会选择一个,然后如果你需要另一个,就烧掉那座桥并为此支付技术债务。
这个聚会迟到了,但只是一个简短的说明:
Salesforce API 并不完全是 RESTful:我称之为 REST-ish。它的某些 REST 接口的 URL 中有类似 SQL 的查询,诸如此类。
SOAP API:
它是干什么用的?使用 SOAP 将组织的数据与其他应用程序集成。
什么时候使用它?您有需要使用 WSDL 和 XML 数据的预先存在的中间件服务。
协议 SOAP/WSDL 数据格式 XML 通信 同步
休息API:
它是干什么用的?使用 REST 访问组织中的对象。什么时候使用它?您希望利用 REST 架构与您的组织集成。没有 WSDL 要求。非常适合基于浏览器的应用程序、移动应用程序和高度交互的社交应用程序。协议 REST 数据格式 JSON、XML 通信同步