ServiceStack与ASP.Net Web API的比较

Question

ServiceStack与ASP.Net Web API的比较

servicestackasp.net-web-api

301

我想编写一个新的REST风格的API，看过ServiceStack后感觉不错。然而，我发现微软已经发布了ASP.Net Web API项目作为新版MVC 4的一部分。有人研究过这个新的Web API项目吗？您能说出每个系统的优缺点吗？

- flipchart

5个回答

139

现在有一个新的主要区别需要考虑 - ServiceStack从版本4开始不再免费使用。 由于SS专业版已经有了相当明确的答案，我想为Web API提供一些方便之处。

Web API

优点:

可自由使用于您的项目中（前提是您拥有允许商用的VS许可证）
来自Microsoft和整个网络的非常高水平的免费支持，包括StackOverflow.com上的支持。
快速与其他微软技术栈集成，如广受欢迎的ASP.NET MVC。
Microsoft堆栈中内置的RESTful身份验证和授权支持。

缺点:

不支持SOAP。

附加好处

（请随意在下面留言，以补充Web API的优点或缺点）

- PW Kad

88

不确定不支持SOAP是否有缺点。 - D.Rosado

11

MVC 和 WebAPI 同时存在的事实是不合理的。 - Phill

4

ServiceStack v3目前仍可免费使用，据我所知将来也会一直是免费的。我认为Mythz提到的内容与v4无关。 - Kyle Gobel

14

“不再免费”这个说法有所保留。对于超过十名员工的公司，每名开发者需支付999美元？ - Ryan Lundy

7

我转换使用Web API的最大原因是Service Stack v3不再支持新的64位架构要求下的iOS（使用Xamarin）。当然，更新在付费版本v4中。 - SgtRock

显示剩余15条评论

21

关于ServiceStack，我无法多做评论，但是Web API有很多出色的功能，并且目前已经更新到版本2。

使用Web API可以做以下事情：

在OWIN应用程序中进行自托管（即可以在任何地方运行）。
完全支持async和await。
良好的默认模板和大量开源示例。
使用了出色的Json.Net JSON序列化器。
默认情况下为REST-ish（您需要自己处理超媒体）。
等等...

- user3377837

1

这个列表中的所有内容都可以在ServiceStack中找到，或者可以看作是缺点。虽然ServiceStack的JSON序列化器不太流行，但它比JSON.NET快得多（请参见真实世界性能和基准测试）。由于@mythz对OWIN技术持有强烈的反对意见，因此不太可能实现OWIN支持，这些意见相当合理（请参见他在此功能请求上的评论）。 - ygormutti

3

看着三年前发布后一直没有升级的OWIN nuget包，我真的不明白为什么这么多人对OWIN支持如此狂热。看起来人们只是因为微软曾经表示它很酷而想要拥有OWIN。否则你可能永远都不会听说过OWIN。微软很高兴地放弃了OWIN，转而支持他们的新玩具K。这减轻了"微软支持所以它会永远存在"这一论点，因为微软有一个强烈的倾向，会淘汰那些受到他们大力推动的项目。 - Alexey Zimarev

如果你没有使用过ServiceStack，为什么要回答这个问题呢？ - Brian Ogden

6

作为ServiceStack的客户，以下是最重要的优点对我来说。

在这里发现问题、确定问题并解决问题都可以在同一天内完成。这种非凡的支持让人印象深刻！ https://github.com/ServiceStack/Issues/issues/606

- labilbe

3

我使用SS已经一年了，一切都很棒。ORMLite是纯粹的魔法。我能够重新映射一个糟糕的MySQL数据库以集成到移动应用程序中。没有对数据库进行任何更改，因为它与另一个应用程序的php后端一起使用...

Mythz是支持和解释的典范。它提升了我的应用程序设计知识和维护简单性。请尝试一下，你就会明白。

此外，请不要将SS与WebAPI进行比较。这还不够，SS为您的工具箱带来了更多。ServiceStack.Text也是一个很棒的自动映射工具。

- André Leblanc

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- mythz · Accepted Answer

我是一名有用的助手，可以进行翻译。以下是需要翻译的内容：

它们具有非常相似的用例，作为ServiceStack项目的主要维护者，我对ServiceStack的优势和其基于消息的设计的许多自然优点有很好的了解。

ServiceStack自2008年以来一直是一个开源项目，从一开始就有一个单一的目标，即推广正确的无摩擦远程服务的设计和实现。

简单而优雅的设计

为了追求最终的简单性，它建立在一个简单而优雅的核心之上 - 大多数功能自然地绑定到您的模型，而不是您的控制器 - 这就是MVC、WebApi所做的事情（以及微软生产的每个其他Web服务框架）。

采用基于消息的设计为远程服务提供了一种更优越的方法，因为它们促进了更具可扩展性和更少脆弱性的服务，简化了访问和调用模式，并且包含许多其他自然的免费好处。

作为核心任务，我们在每个阶段都与复杂性斗争，在保持隐形和非侵入式 API 的同时，避免引入任何新的概念或人工结构，这些概念或结构不是今天 .NET 或 Web 服务开发人员已经熟悉的。

例如，您的 IService<T> 服务实现只是一个带有自动连接依赖项的标准 C# 类。使用薄而轻的包装器来提供围绕核心运行时 IHttpRequest 和 IHttpResponse 类的一致和统一的 API。它们还允许访问底层 ASP.NET 或 HttpListener 的 Request 和 Response 类，因此在使用 ServiceStack 时永远不会受到限制。

与WCF和WebApi相比

以下是ServiceStack和WCF推广的截然不同的API风格的简要概述。WebApi与WCF不同，它鼓励RESTful API设计。至于两者之间的示例，这是我所知道的唯一一个使用ServiceStack和WebApi编写相同服务的示例。

远程服务最佳实践

ServiceStack主要关注简单性、性能和促进以尽可能符合C#语言习惯的方式来采用Martin Fowler的远程服务设计模式为中心的网络/远程服务最佳实践：

门面模式 - 建议在跨进程边界通信时使用批处理、粗粒度接口。
DTO模式 (MSDN) - 规定使用特定目的的POCO生成您的Web服务响应的线格式。
网关模式 (MSDN) 用于封装客户端网关/DTO模型和服务接口层之间的客户端和服务器通信。

这些模式确保了关注点的清晰分离和无摩擦的迭代开发体验。

增强您的服务

一个ServiceStack web服务的核心是一个无依赖且自动连接的纯C# IService<T> 接口，它让你完全自由地定义你的web服务合同，使用干净的POCOs来定义你自己的请求和响应DTOs。这使得ServiceStack的API几乎是不可见和非侵入性的，也就是说，提取你的C#服务逻辑并在ServiceStack主机之外运行它是微不足道的。

这个要点是一个很好的例子，展示了你在ServiceStack中只需要一个C# .cs类就能获得什么：just 1 C# .cs class in ServiceStack。

为所有注册格式提供元数据页面
- 包含指向WSDL、XSD和C#客户端示例的链接
人性化的HTML报告视图
- 单个自包含的HTML页面快照（即没有外部引用）。包括嵌入式JSON Web服务响应-允许对数据快照进行编程访问。
内置Mini Profiler（优秀MVC Mini Profiler的端口）
- 包括Sql分析
JSON/JSONP、XML、JSV、CSV和SOAP端点

RestServiceBase和ServiceBase类旨在托管您的自定义C＃逻辑，以实现最大可能的重用，例如，其基于DTO的设计轻松地允许延迟和代理执行，在这种情况下，您的同一C＃服务也可以托管并在MQ主机中执行，这是当您注册一个IMessageService像RedisMQ host并通过/asynconeway端点调用服务时发生的（即在C＃客户端中的client.SendOneWay()）。

您还可以使用base.ResolveService<T>()方法轻松委派和创建复合服务，该方法返回所选服务的自动连接实例，如Nortwind CustomerDetails Service示例所示。

var ordersService = base.ResolveService<OrdersService>();
var ordersResponse = (OrdersResponse)ordersService.Get(
    new Orders { CustomerId = customer.Id });

返回纯C#对象

大多数情况下，ServiceStack会将大部分C#对象序列化为预期结果 - 这里是可能的返回类型列表(来自这个答案):

任何DTO对象 -> 序列化为响应ContentType
HttpResult、HttpError、CompressedResult(IHttpResult)用于自定义HTTP响应

以下类型不会被转换，并直接写入响应流:

字符串
流
IStreamWriter
byte[] - 使用application/octet-stream内容类型。

可以通过此CORS示例查看自定义HTTP标头支持的示例，您可以在全局或每个服务基础上配置HTTP标头。

HTML支持

在ServiceStack中，有多个返回HTML的选项，这些选项在此处详细解释。

包括.NET最快的文本和二进制序列化程序

具备弹性和快速序列化程序对于API来说是非常重要的，以确保快速响应时间和可版本化的API，不会破坏现有客户端。这就是为什么ServiceStack包含了.NET中最快的文本序列化程序，并提供NuGet选项来启用@marcgravell的Protocol Buffers（.NET中最快的二进制序列化程序）。

ServiceStack的文本序列化程序非常强大，可以承受极端版本控制而不出错。

无摩擦的端到端开发体验

ServiceStack的主张性质允许快速、类型化、简洁的Web服务API端到端，内置对Sync/Async C#/.NET和Async Silverlight clients的支持，无需任何代码生成：

同步C#示例

var response = client.Send<HelloResponse>(new Hello { Name = "World!" });

异步 C# 示例

client.SendAsync<HelloResponse>(new Hello { Name = "World!" },
    r => Console.WriteLine(r.Result), (r, ex) => { throw ex; });

由于它只返回纯JSON，因此也可以轻松地与其他HTTP客户端一起使用，例如使用jQuery的JS客户端示例：

$.getJSON("http://localhost/Backbone.Todo/todos", function(todos) {
    alert(todos.length == 1);
});

易于测试

所有的C#/.NET服务客户端共享相同的接口，使它们易于测试和可交换，以至于您可以将同一单元测试用作XML、JSON、JSV、SOAP集成测试。

内置丰富的验证和错误处理

为了提供无摩擦和清洁的开发体验，ServiceStack还包括类型化验证和错误处理内置功能，其中抛出C#异常或使用其内置流畅验证提供的结构化、类型化错误易于在Web服务客户端上访问，例如：

try {
    var client = new JsonServiceClient(BaseUri);
    var response = client.Send<UserResponse>(new User());
} catch (WebServiceException webEx) {
    /*
      webEx.StatusCode  = 400
      webEx.ErrorCode   = ArgumentNullException
      webEx.Message     = Value cannot be null. Parameter name: Name
      webEx.StackTrace  = (your Server Exception StackTrace - if DebugMode is enabled)
      webEx.ResponseDto = (your populated Response DTO)
      webEx.ResponseStatus   = (your populated Response Status DTO)
      webEx.GetFieldErrors() = (individual errors for each field if any)
    */
}

为了方便在JavaScript中使用错误，您可以使用轻量级的ss-validation.js JavaScript库，通过一行代码将响应错误轻松绑定到HTML表单字段。SocialBootstrapApi示例项目提供了一个很好的演示。

与ASP.NET和MVC的深度集成 ServiceStack MVC PowerPack重新编写和修复了ASP.NET和MVC的许多问题，用自己干净且无依赖的ICacheClient和ISession API实现替换了其妨碍Session和缓存XML的ASP.NET提供程序。

ServiceStack还包括一个更新和更清晰的身份验证和授权提供程序模型，内置了许多不同的AuthProviders：

Credentials - 通过向/auth/credentials服务发送带有用户名/密码凭据的请求进行身份验证
Basic Auth - 允许用户使用基本身份验证进行身份验证
Twitter OAuth - 允许用户使用Twitter注册和身份验证
Facebook OAuth - 允许用户使用Facebook注册和身份验证

身份验证模块完全是可选的，并构建在干净的ICacheClient / ISession API和OrmLite之上，这允许将您的会话存储在Memory、Redis或Memcached中，将UserAuth信息持久化在OrmLite支持的RDBMS（如SQLServer、MySql、PostgreSQL、Sqlite）以及Redis数据存储或InMemory中（对于开发/测试非常有用）。

完美的文档

ServiceStack非常好文档化，大部分关于框架的信息都托管在GitHub wiki上。其他部分框架（例如：序列化器、Redis、OrmLite）的文档可以在servicestack.net/docs/上找到。

ServiceStack.Examples项目提供了所有ServiceStack实时演示和Starter模板的源代码，而SocialBoostsrapApi项目则提供了一个很好的起点，基于Twitter Bootstrap模板，使用ServiceStack和MVC来开发Backbone.js单页应用。

除上述内容外，还有大量信息包含在Google Group中，近年来得到了相当的扩展。

Runs Everywhere

ServiceStack是一个运行在ASP.NET和HttpListener主机上的.NET 3.5框架，可以在.NET或Mono上托管（趣闻：www.servicestack.net由CentOS/Mono提供支持）。这使得您的ServiceStack Web服务可以托管在以下任一平台上：

Windows平台，包括.NET 3.5和4.0

IIS 5/6/7（使用IHttpHandler）
VS.NET WebDevServer
控制台应用程序或Windows GUI
Windows服务

Linux/OSX平台，包括Mono

Apache + mod_mono
Nginx + MonoFastCGI
XSP
控制台应用程序

采用开源开发模式开发

ServiceStack坚信开源开发模式，积极参与开放式开发并始终以自由的OSS许可证（New BSD）作为其主要托管方式。截至今日，它已经收到了来自47位开发者的贡献，并且目前是GitHub上第三个最受关注的C#项目。

缺点

我认为最大的缺点和其他大多数.NET项目一样，它没有被微软开发（甚至没有被列为可用选项）。这意味着在评估框架时，它很少是第一个选择。大多数采用者只会在WCF的摩擦和脆弱性或首选的Microsoft Stack的性能令人沮丧时，将ServiceStack作为最后一个选择来考虑。

反馈和社区资源

ServiceStack 受到了广泛的欢迎，大多数评估过它的人都给予了积极的反馈，这可以从邮件组中积极情绪的表现看出。截至今年，@ServiceStack 推特账户一直在跟踪提及和反馈。

社区资源维基页面是一个了解 ServiceStack 的好去处，其中包含博客文章、播客、演示文稿、代码片段等链接。