RESTful和SOAP Web服务在实践中有何不同？
我正在为PHP应用程序实现Web服务，并试图了解标准Web服务和RESTful Web服务所提供的内容。 我的目的是编写包装器代码以抽象出Web服务细节，以便开发人员可以“实例化远程对象”并使用它们。 以下是我的想法，也许你们中的一些人可以添加你的经验并扩展它：
RESTful Web服务
基本上只是“按需提供XML源”，因此您可以为客户端应用程序编写包装器代码，以便它可以通过以下方式查询服务器应用程序：
$users = Users::getUsers("state = 'CO'"); - 这将反过来从远程URL获取XML提要
- $ users可以被制作成完整User用户对象的集合，或者
- 保留为XML，或
- 变成arrays等
- 查询脚本（“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实现可以做得更多。
很乐意听取您的反馈意见，以清理其中的一些云。
它们是不同的模型…… REST是以数据为中心的 ，其中SOAP是以操作为中心的 。 即使用SOAP，您往往会有离散操作“SubmitOrder”等; 但是使用REST，您通常会更加关注如何查询数据。
SOAP往往与更复杂的关联（有时是必要的） – REST回到POX等，以及YAGNI 。
就.NET而言，像“wsdl.exe”这样的工具将为您提供一个完整的客户端代理库来表示SOAP服务（或者用于WCF服务的“svcutil.exe”）：
var someResult = proxy.SubmitOrder(...);
对于REST with .NET，我想ADO.NET Data Services是最明显的玩家。 在这里，工具（datasvcutil.exe）将为您提供具有LINQ支持的完整客户端数据上下文。 LINQ是.NET相对较新的形成复杂查询的方式。 所以像（强/静态类型检查和intellisense）：
var qry = from user in ctx.Users where user.State == 'CO' select user;
（这将被转换为ADO.NET数据服务的相应REST语法）
我在回应Marc Gravell提到的内容。 当人们向我询问REST（他们通常对SOAP和SOA有所了解）时，我会告诉他们REST = ROA，因为它是面向资源/数据的，它是一个不同的范例，因此有不同的设计问题。
对于您的情况，如果我正确地阅读您，您希望避免编写包装器代码并需要一个可以远程存储对象及其属性的解决方案（并将它们完全隐藏在开发人员之外）。 我真的不能建议一个更好的解决方案..嗯，如果其中任何一个接近满足您的要求，请告诉我：
- EJB3 / JPA
- CouchDB （REST / JSON）
如果我错误地解释了你的问题，请告诉我。
如果我们比较XML-RPC和SOAP，后者将为您提供更好的数据类型处理，对于前者，尽管您将处理更简单的数据类型，但您必须编写一个层或适配器将它们转换为您的域对象。
YC
Soap只是标准组祝福的一套商定的XML模式。 它的优势在于它是为互操作性而设计的，它支持许多企业级function。 任何平台上的肥皂都不会提供您正在寻找的操作。 您需要设计并实施服务合同才能获得这些function。
听起来你想要Soap或REST特别适合的远程对象。 也许你最好不要看XML-RPC 。
关键差异基本上是工具。
许多高端SOAP堆栈将大量的SOAP基础架构从开发人员转移到几乎完全使用DTO / Documents和RPC的地方。
REST over HTTP会给开发人员带来更多的负担（协商格式[XML，JSON，HTTP POST]，解析结果[DOM，地图，DTO编组等]）。
显然，您可以编写一层逻辑，以便更轻松地处理此细节。 并且一些REST框架已经到位，以使这更容易，但目前，当您希望使用或使用此类服务时，它仍然是您的TODO列表上的任务。
我的反馈是，如果你想要远程状态，你不是在谈论Web服务。 我不知道任何处理远程状态的现代模型。 我认为，如果你需要远程状态，你就是自己（没有宗教信仰）。 把xml从这里扔到那里，不介意理论。
我必须补充说远程状态是邪恶的。 如果可以，请避免使用它。