服务站

多个在 REST

Jon Flanders

内容

这是更好地，REST 或 SOAP？
安全呢？ 那么现在 SOAP REST 比更安全吗？
交易记录呢？
互操作性？ 那么现在 SOAP 应该是有关互操作性吗？ 那么 SOAP 现在更多 REST 比可互操作吗？
但元数据呢？ 因此如果 REST，因此可互操作） 有不使用 REST，WSDL，WSDL，而我不能生成调用服务客户端代理。 REST 是难以使用。
如果要使用非 HTTP 传输吗？
所有这些信息后不您告诉我 REST 适合面向 Internet 的应用程序和 SOAP 的企业应用程序吗？
底端行

最后两个列中, 我已经描述 REST 的基础知识，讨论公开和使用 Web 源。 在本专栏中，我将回答问题通常会使演示文稿或进行培训会话，使用 REST 生成基于服务的应用程序时的一个数。

这是更好地，REST 或 SOAP？

这是最常见的问题得到有关 REST，并且可能最合理。 REST 和 SOAP 通常称作"Web 服务，"和一个通常用来代替其他，但它们是完全不同的方法。 REST 是用于构建客户端-服务器应用程序的体系结构风格。 SOAP 是协议规范，用于在两个终结点之间交换数据。

REST 进行比较生成客户端-服务器应用程序的远程过程调用 (RPC) 样式会更准确。 RPC 是一种样式 （而不是什么 SOAP 协议） 生成客户端-服务器应用程序的代理服务器 （通常从元数据生成） 用于在客户端的地址空间与服务器通信，代理的接口模仿服务器的接口。 尽管 SOAP 不要求 RPC 样式，但大多数的现代 SOAP 工具包面向 （至少它们默认为） 使用 RPC。

相对于 RPC，REST 缺少元数据生成代理 （请参阅下一个问题的详细信息） 小于耦合到服务这意味着客户端。 此外，因为 REST 依赖于 HTTP 的语义可以缓存的数据 （GET 请求） 的请求。 RPC 系统通常有没有这样的基础结构 （和即使执行通过 HTTP 使用 SOAP RPC，SOAP 响应不能被缓存，因为 SOAP 使用 HTTP POST 谓词被认为是不安全的）。 SOAP 有意 eschews HTTP，特别允许 SOAP 工作通过其他的协议，使其实际有点 disingenuous 调用 Web 服务基于 SOAP 的服务。

我的角度来看是 REST 和 SOAP 可用于实现类似的功能，但一般情况下在需要的 SOAP 某项特定功能，并 REST 的优点使其通常最佳的选择否则时应使用 SOAP。

安全呢？ 那么现在 SOAP REST 比更安全吗？

此问题涉及我的宠物 peeves 之一是答案显然没有。 也很轻松使 RESTful 服务的安全，因为它使一个基于 SOAP 的服务的安全。 在涉及 REST 或 SOAP 的情况下，大部分安全系统是相同的： 某种形式的基于 HTTP 的身份验证和安全套接字层 (SSL)。 尽管从技术上讲，技术通过 HTTP 的安全对话现在称为传输层安全性 (TLS)，SSL 仍是最常用的名称。

真是基于 SOAP 的服务由于的额外的协议中指定各种 WS-* 规范、 是否支持端到端的消息安全。 这意味着如果您传递 SOAP 消息终结从终结点到点给终结点，通过相同或不同的协议消息安全。 如果您的应用程序需要此某些特定的功能 SOAP 加 WS-* 是已明确进入的方法。 REST 可能不是此处的选项因其依赖 HTTP，并且本质上您希望将设计一个多协议的应用程序。 我认为这一事实的 SOAP 与 WS-* 启用端到端的邮件级安全机制是基于 SOAP 的服务的 RESTful 服务比更安全，误解的源。

在另一个区域，WS-* 人员花费了大量的时间，投入比最近联合的安全。 联合身份标识后面简单思路是创建两个公司可以受信任的和被认为是一家公司已通过身份验证的用户之间的信任而不必维护身份验证信息在第二个公司的另一家公司通过身份验证 （用户名和密码，通常）。 各种 WS-* 规范所有主要供应商的实现都 Microsoft 将该想法集成到 Active Directory 通过 Active Directory 联盟服务 （ADFS）。

联合安全 WS-的领域中 * 领地肯定有 RESTful 的空间比多个标准 （和这可能是始终将继续这种情况） 但还有工作以支持联合的安全 REST 的世界。 OpenID 是一类工作。 .NET 服务总线 （Windows Azure 的一部分） 还包含一个联合身份标识服务的工作原理也只是与 HTTP （因此 REST） 作为它会与基于 SOAP 的服务。

交易记录呢？

下面是另一个区域的 SOAP 和 WS-* 显式支持的"高级"功能都 REST 没有。 WS 原子事务支持基于 SOAP 的服务上的分布式、 两阶段提交事务语义。 REST 具有不支持分布式事务。

通常情况下，如果希望交易记录类似于 RESTful 系统中，您创建一个新的资源。 （创建新的资源，您通常运行到 RESTful 系统问题时解决大多数问题）。 您可以有一个称为事务。 当您的客户端需要执行某些操作 （如两个银行帐户之间转移资金） 事务时，客户端将创建事务资源，指定所有正确的资源 （在我示例两个银行帐户） 受执行 POST 事务工厂 URI。 客户端可以通过向 URI 交易记录的一个 PUT 执行更新然后通过发送一个 Delete URI 关闭交易记录。

当然，需要一定量的现有编码和显式控制您的系统而 WS 原子事务系统正多自动的因为 （在 Windows 通信基础） 的情况下它取决于运行库的管道。

如果您的系统绝对需要跨不同系统的原子事务语义，WS 原子事务可能是到方法。 这种方式使用分布式的事务可能也可能不智能因为它增加了在两个系统之间的耦合并创建潜在的问题，如果您不能控制两端代码。 但是，最重要是右作业使用合适的工具，（一旦您已经确定右作业）。

在 REST 的防御，我认为这样严格使用分布式的事务可能不是最好的设计是博览会说该给定的当今的分布式面向服务的体系结构、 耦合两个终结点。 而在另一方面，某些情况下调用此类功能，并用需要，SOAP 和 WS 原子事务。

互操作性？ 那么现在 SOAP 应该是有关互操作性吗？ 那么 SOAP 现在更多 REST 比可互操作吗？

如果为两个分歧的终结点之间的通信技术能够定义互操作性，我断言 REST 动手下获胜的互操作性战斗的行列。

因为推动点后面创建 SOAP 规范之一来创建不同的平台和不同语言之间进行通讯的互操作方法，许多人在通过此断言是对惊讶。 一个有趣的事情发生在广泛互操作性，但是： WS-* 规范 （和上述规范的供应商实现） 进行 SOAP 服务更少的互操作而不是更多的互操作。

该问题在 SOAP WS-* 领地是大量不同的标准的 （而这些标准的每个版本），它可供选择。 并实现一个特定的标准选择特定供应商时, 该供应商通常提供了另一只需稍有不同的实现供应商的 （或其他所有人）。 这将导致问题时需要跨供应商边界 （语言和鎿嶄綔绯荤粺）。

当然，甚至还可以使用 SOAP 您需要一个 SOAP 工具包在您的平台上的大多数 （但不是所有） 平台今天。 然后处理各种 WS-* 规范和算出要使用 （或不使用） 以及如何影响互操作性。 若要坦白地讲的类型的一个一塌糊涂之外。

方面的平台，REST 有这样一个 HTTP 堆栈 （或者在客户端或服务器上） 是您需要使用 REST 优势。 因为几乎每个平台和设备的当前，我会认为 REST 了最大互操作性。 给定的移动设备、 家庭设备、 POS 设备、 DVD 播放机和电视所有 Internet 连接，有对于具有一个完整的 SOAP 工具包是不可能或不可能的多平台。 即使您执行特定平台的一个 SOAP 工具包，使用另一个平台实现它的可能性不 100%。

但元数据呢？ 因此如果 REST，因此可互操作） 有不使用 REST，WSDL，WSDL，而我不能生成调用服务客户端代理。 REST 是难以使用。

这是在世界里 REST 没有从服务器端生成的元数据中生成客户端不直接支持因为在 SOAP Web 服务描述语言 (WSDL) 的领域。 几个工作的进行进入一个被称为 WADL （Web 应用程序说明语言） 一个并行规范的 REST 的类的支持。 另一个是一个强制使用 WSDL 2.0 描述 RESTful 端点。 我通常说 REST 是简单，但简单并不总是意味着变得容易。 SOAP 是容易 （由于 WSDL)，但简单并不总是意味着简单。

是，使用 WSDL 可生成比编写代码更容易基于 SOAP 的服务的代理服务器调用 RESTful 服务。 但一旦您生成的代理服务器，您仍然必须了解 API。 在 WSDL 中没有告诉您哪种方法调用的第一个或第二个或您是否需要在任何特定顺序调用的方法。 这些是您需要生成代理和是原型代码，以使用该服务后，计算出的所有内容。

构建 RESTful 服务对客户端，意味着您将学习服务以及如何在构建客户端。 已完成后您对有了完整的了解，服务、 它的资源和您可以使用这些资源交互。 我，这是一个大的好处。 因为 RESTful 服务按照 REST 的约束 （至少它们应该），没有一种规则可以很容易地按照确定服务的不同部分。

此外，出的开发人员的土地，在 wilds 中大多数服务封装在某些通常称为"服务代理，"这是另一层间接寻址，以防止客户端服务层中的更改。 这可能需要在 REST 或 SOAP。

另一个点是元数据生成的代理服务器的 SOAP 的含义获得开中 RPC 纪元，即本地远程透明部分。 匹配 API 在服务器上的客户端上有一个 API 的概念被认为是一个坏的主意，但这正好发生在大多数基于 SOAP 的服务。 在 REST 中遇到生成元数据的代理服务器还可减少 hyperlinking 利用的可能性。 为应用程序状态的引擎使用超文本 （HATEOAS） REST 的约束的并使用它需要更松散耦合的客户端 API。

我将进行最后的点是支持对 REST 变得更无处不生成客户端将获得更容易、 更容易。 如果您查看在 Windows 通信基础 （WCF） REST 初学者工具包它包括在此方向的头的功能。 新 HttpClient API 使使用 HTTP 比使用.NET WebRequest/WebResponse API 更容易。 此外，作为 XML 可序列化工具使您可以复制一段 XML （假设 RESTful 终结点的文档中） 和生成.NET 类型可以表示在应用程序中的 XML 实例没有一个新的粘贴。 它类似于 WCF 工具做什么自动为整个服务使用 WSDL。 随时间，这些工具将变得更复杂的使用 RESTful 服务时进一步简化客户端在 WCF 中的体验。

如果要使用非 HTTP 传输吗？

公共 （有些 sarcastic） 从 REST 社区答案、"向前定位，没有任何您停止。 实际，但是，REST 当前绑定到 HTTP，如果大多数开发人员和团队的开发人员没有工程努力 REST 的语义所需通过，工作时间，因此只说，TCP/IP。

常见答案是从技术上讲正确，因为没有正在停止从实现通过其他的协议 REST 的概念，但供应商添加对此支持，直到我发现它对于大多数一个可疑主张。

所有这些信息后不您告诉我 REST 适合面向 Internet 的应用程序和 SOAP 的企业应用程序吗？

如果您已经阅读了本专栏的其余部分，您可能可以想象我认为此语句是通用和 false。 通常我听到这个 sentiment 之后缺少的 WS 原子事务中显式支持与在 REST 中的显式分布式的事务支持。 我 retort 通常是类似就绪，ASP.NET 不具有对分布式的事务支持但不是意味着 ASP.NET 不用于企业？

我的点是不是每个技术解决每个问题，并且有大量不支持在典型的功能的人的技术考虑当他们认为企业的但企业极其有用但。

实际上，相信的企业级应用程序时我通常认为速度和可伸缩性） 的一个主要区别 REST 和 SOAP 的可伸缩性。 SOAP 服务是很难缩放比 RESTful 服务是当然，REST 通常选择为通过 Internet （如 Facebook MySpace、 Twitter 和等等） 公开的服务体系结构的原因之一。

企业，内部应用程序还经常需要以及缩放。 使用 REST 意味着您可以采取的 HTTP 缓存的优点和其他功能，类似条件 GET 帮助扩展服务的。 其中许多技术不能使用 SOAP 因为 SOAP 仅通过 HTTP 使用 POST。

底端行

希望您阅读此专栏后，您会认为答案"的是更好地，REST 或 SOAP？"是"它决定"。 在 REST 体系结构风格和 SOAP 和 WS-* 时涉及到构建服务协议有优点和缺点。 我们在该 RESTafarian camp （是，我必须给出完整泄露此处： 我肯定该 camp 中） 认为对于大多数有关服务的情况下提供 REST 了多个优点是 SOAP 或 WS-*。 在 SOAP 和 WS-手动 * 具有一些功能的简单和可能的实现使用 REST。 当您需要这些特定功能时，一定要使用运行时，可以提供这些功能的工具包。 尽管此列不是特别有关 WCF，采用 WCF 的一个不错的功能是它支持 SOAP/WS 和 REST 的 *。 在两个世界之间来回移动变得更容易，如果您有一个编程和运行时模型学习。

将您的问题和提出发送到 sstation@microsoft.com.

Jon Flanders 是独立的顾问、 扬声器和培训师 Pluralsight 的。 他专门负责在 BizTalk Server、 Windows 流基础，和 Windows 通讯的基础。 您可以与在 Jon masteringbiztalk.com/blogs/jon.