我一直在尝试对CentOS / Redhat的REST和SOAP Web服务支持框架进行一些研究，这些框架也能够合理地支持管理Web应用程序以及服务本身。
我们还没有确定REST或SOAP是否是进行服务通信的方式。通信要求非常简单，因此可能不需要更重的SOAP接口。 （但也不复杂）
我过去曾经使用过Ruby on Rails（当前就是这方面），但是这个技术并不像J2EE那样熟悉我的其他人。
ServiceStack也很有意思（我现在正在研究它），但我过去曾参与过.Net / Mono项目，并遇到过各种Mono实现和运行时问题。 （我相信在过去的两年中它已经走了很长一段路，但我想看看是否有更好的选择）
基本上我需要一个支持REST或SOAP的堆栈/框架（两者都很棒）并且可以支持MVC风格的Web应用程序。想法是Web服务和Web应用程序可以访问同一个数据库。 Web应用程序将是最终用户/管理员管理界面，Web服务将用于远程系统/自动访问受控数据。
最后，大约80％的应用程序数据库架构将被预定义，并且不会遵循任何MVC样式建模。因此，一个仅用于MVC的架构数据的框架，就像Ruby on Rails一样，不会更好，因为我们最终不得不重新创建模型或编写一个完全独立的数据库查询处理库。 Web服务和Web应用程序都必须使用。如果现有数据可以更灵活地建模，那将是很好的。 （如果现有架构在以后更改）
很抱歉，如果我太通用了。 （或具体）我只是对意见感兴趣。谢谢！
答案 0 :(得分：10)
REST和SOAP是不同的方法，尽管ServiceStack基于消息的DTO优先方法是唯一的.NET框架，它允许REST和SOAP调用相同的服务端点。由于您的ServiceStack Web服务是纯C＃服务，因此同一服务也可以托管在InMemory或Redis MQ Host中。 （还有一个RCON非http上下文host option）。
虽然SOAP通过 HTTP Post 路由所有内容，但您需要围绕此限制定义服务，并为SOAP端点中可用的每个服务提供一个新类。以下是如何创建was also available via SOAP。
的REST服务的示例答案 1 :(得分：5)
REST和SOAP在很多方面都有很大不同。
REST是一种架构风格，SOAP是一种协议。 SOAP定义了事物的通信方式，REST定义了无状态描述的方式。
我更喜欢REST与HATEOAS（超媒体作为应用程序状态的引擎）。具有该体系结构的应用程序使用内容协商（在HTTP上接受标头）为这些资源公开具有特定URI（如http://example.com/users）和表示（使用JSON，XML，HTML等）的资源。
HATEOS部分是资源之间的链接，例如HTML上的<a href=或ATOM上的<link href=或JSON中的JSON模式。
一个很好的参考实现是Netflix API http://api.netflix.com/。他们太棒了。
RESTful实现的框架可用于多种语言。在Ruby上，Sinatra可能是最好的选择。 Flask将成为Python的人。在node.js上，expressjs越来越流行。
我是一个PHP家伙。在我所知的所有框架中（包括Zend，Symfony，Slim，Code Igniter等），最好的REST实现是http://documentup.com/Respect/Rest。它是唯一一个以理智的方式实现内容协商的人。 （免责声明：我编写了它，我的意见可能有偏见。使用类似于适用于RESTful框架的Litmus测试http://code.google.com/p/implementing-rest/wiki/LitmusTestForFrameworks）获取您自己的意见。
有一种情况我更喜欢SOAP通信：当使用我的服务的客户端已经将SOAP用于其他任何事情时。在这种情况下，一致性获胜。我相信Java家伙也可能更喜欢SOAP。