RESTful 和 SOAP Web 服务在实践中有何不同？

Question

我正在为 PHP 应用程序实现 Web 服务，并试图了解标准 Web 服务和 RESTful Web 服务必须提供什么。 我的目的是编写包装器代码来抽象 Web 服务详细信息，以便开发人员可以“实例化远程对象”并使用它们。 以下是我的想法，也许你们中的一些人可以添加您的经验并扩展它：

RESTful Web 服务

基本上只是“按需 XML 提要”，因此，例如，您可以为客户端应用程序编写包装器代码，以便它可以通过这种方式查询服务器应用程序：

$users = Users::getUsers("state = 'CO'");

• 这将依次从远程 URL 获取 XML 提要
• $users 可以被制作成完整 User 对象的集合，或者
• 保留为 XML，或者
• 变成数组等。
• 查询脚本("state = 'CO'") 将在服务器端转换为 SQL

• 从客户端的角度来看，RESTful Web 服务通常是只读的，尽管您可以编写可以使用 POST 或 GET 来实现的代码服务器上的更改，例如传递加密令牌以确保安全，例如：

  $users = Users::addUser($encryptedTrustToken, 'jim',$encryptedPassword, 'James', 'Taylor');

这将在服务器应用程序上创建一个新用户。

标准 Web 服务

标准 Web 服务最终基本上做同样的事情。 他们的优势之一是客户可以通过 WSDL 发现他们的详细信息。 但除此之外，如果我想编写允许开发人员远程实例化、编辑和保存对象的包装器代码，我仍然需要实现包装器代码。 SOAP 不会为我做任何事情，它可以做到这一点：

$soap = new nusoap_client('http://localhost/test/webservice_user.php?wsdl', true);
$user = $soap->getProxy(); 
$lastName = $user->lastName();

但如果我想编辑和保存：

$user->setLastName('Jones');
$user->save();

那么我需要例如处理服务器端的所有状态，SOAP 似乎不保留该对象每个客户端的服务器端。

也许我正在使用的 PHP SOAP 实现 (nusoap) 存在限制。 也许 Java 和 .NET 实现可以做更多的事情。

我们很高兴听到您的反馈意见，以消除其中的一些阴云。

Answer 1

它们是不同的模型... REST 是以数据为中心，而 SOAP 是以操作为中心。 即，使用 SOAP，您往往会进行离散操作“SubmitOrder”等； 但使用 REST，您通常可以更加灵活地查询数据。

SOAP 也往往与更多的复杂性相关联（有时这是必要的）——REST 又回到 POX 等，并且 YAGNI。

---

就 .NET 而言，“wsdl.exe”等工具将为您提供完整的客户端代理库来表示 SOAP 服务（或用于 WCF 服务的“svcutil.exe”）：

var someResult = proxy.SubmitOrder(...);

对于使用 .NET 的 REST，我猜是 ADO .NET 数据服务是最明显的参与者。 在这里，工具 (datasvcutil.exe) 将为您提供具有 LINQ 支持的完整客户端数据上下文。 LINQ 是 .NET 形成复杂查询的相对较新的方法。 所以类似（具有强/静态类型检查和智能感知）：（

var qry = from user in ctx.Users
          where user.State == 'CO'
          select user;

这将转换为 ADO.NET 数据服务的适当 REST 语法/从适当的 REST 语法转换为 ADO.NET 数据服务）

Answer 2

我赞同马克·格拉维尔（Marc Gravell）提到的内容。 当人们问我有关 REST 的问题时（他们通常对 SOAP 和 SOA 有一定的了解），我会告诉他们 REST = ROA，因为它是面向资源/数据的，这是一种不同的范式，因此有不同的设计关注点。

对于您的情况，如果我没有正确理解您的意思，您希望避免编写包装器代码，并且需要一个可以远程存储对象及其属性的解决方案（并使它们对开发人员完全隐藏）。 我实在无法提出更好的解决方案。嗯，请告诉我其中任何一个是否接近满足您的要求：

1. EJB3 / JPA
2. CouchDB (REST/JSON)

如果我错误地解释了你的问题，也请告诉我。

如果我们比较 XML-RPC 和 SOAP，后者将为您提供更好的数据类型处理，而对于前者，虽然您将处理更简单的数据类型，但您必须编写一个层或适配器将它们转换为域对象。

yc

Answer 3

Soap 只是一组由标准组认可的、商定的 XML 模式。 它的优势在于它是为互操作性而设计的，并且支持许多企业级功能。 任何平台上的Soap都不会提供您正在寻找的操作。 你需要设计& 实施服务合同以获得这些功能。

听起来您想要的是 Soap 或 REST 都不太适合的远程对象。 也许您最好查看 XML-RPC。

Answer 4

主要区别主要在于工具。

许多高端 SOAP 堆栈覆盖了从开发人员到您几乎仅使用 DTO/文档和 RPC 的大部分 SOAP 基础结构。

REST over HTTP 给开发人员带来了更多负担（协商格式 [XML、JSON、HTTP POST]、解析结果 [DOM、映射、DTO 编组等]）。

显然，您可以编写一层逻辑来使处理此细节变得更容易。 一些 REST 框架已经到来，使这变得更容易，但目前，当您希望使用或使用此类服务​​时，它仍然是您的待办事项列表中的一项任务。

Answer 5

我的反馈是，如果您想要远程状态，那么您就不是在谈论 Web 服务。 我不知道有任何处理远程状态的当代模型。 我认为，如果你需要远程状态，你就得靠自己（没有宗教信仰）。 只需将 xml 从这里扔到那里，不要介意理论。

我必须补充一点，远程状态是邪恶的。 如果可以的话避免它。