适用于 Linux 上的 REST 和/或 SOAP Web 服务开发的堆栈/框架 [关闭]

Question

我一直在尝试对 CentOS/Redhat 的 REST 和 SOAP Web 服务支持框架进行一些研究，这些框架也能够合理地支持管理 Web 应用程序以及服务本身。

我们尚未确定 REST 或 SOAP 是否会成为服务通信的方式。通信要求非常简单，因此可能不需要更重的 SOAP 接口。 （但也不会很复杂）

我过去曾使用过 Ruby on Rails（目前在一边），但我的团队中的其他人并不像 J2EE 那样熟悉这项技术。

ServiceStack 也很有趣（我现在正在研究它），但我过去曾参与过 .Net/Mono 项目，并且遇到过各种 Mono 实现和运行时问题。 （我敢肯定在过去 2 年里它已经取得了长足的进步，但我想看看是否有更好的选择）

基本上我需要一个支持 REST 或 SOAP（两者都很棒）并且可以支持 MVC 风格的 Web 应用程序的堆栈/框架。这个想法是 Web 服务和 Web 应用程序可以访问同一个数据库。 Web 应用程序将是最终用户/管理员管理界面，Web 服务将用于远程系统/自动访问受控数据。

最后，大约 80% 的应用程序数据库架构将是预定义的，并且不会遵循任何 MVC 样式建模。因此，一个旨在对仅用于 MVC 的模式数据进行紧密建模的框架（如 Ruby on Rails）并不可取，因为我们最终不得不重新创建模型或编写一个完全独立的数据库查询处理库， Web 服务和 Web 应用程序都必须使用。如果可以更灵活地对现有数据进行建模，那就太好了。 （以防现有架构在以后更改）

对不起，如果我太笼统了。 （或具体）我只是对意见感兴趣。谢谢！

Answer 1

ServiceStack 服务可以被 REST、SOAP 或 MQ 客户端使用

REST 和 SOAP 是不同的方法，尽管 ServiceStack 的基于消息的 DTO-first 方法是唯一允许 REST 和 SOAP 端点调用相同服务的 .NET 框架。由于您的 ServiceStack Web 服务是纯 C# 服务，因此同样的服务也可以托管在 InMemory 或 Redis MQ Host 中。 （还有一个RCON非http上下文host option）。

SOAP 的固有限制

尽管 SOAP 通过 HTTP Post 路由所有内容，但您需要围绕此限制定义您的服务，并为您希望在 SOAP 端点中提供的每个服务使用一个新类。下面是一个示例，说明如何创建 was also available via SOAP 的 REST 服务。

Answer 2

REST 和 SOAP 在很多方面都非常不同。

REST 是一种架构风格，SOAP 是一种协议。 SOAP 定义事物的通信方式，REST 定义事物的无状态描述方式。

我更喜欢带有 HATEOAS（超媒体作为应用程序状态引擎）的 REST。具有该架构的应用程序使用内容协商（接受 HTTP 上的标头）公开具有特定 URI（如 http://example.com/users）和这些资源的表示（JSON、XML、HTML 等）的资源。

HATEOS 部分是资源之间的链接，例如 HTML 上的 <a href= 或 ATOM 上的 <link href= 或用于在 JSON 中链接的 JSON Schema。

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。