需要考虑一个新的主要差异——从v4开始ServiceStack不再免费使用。既然关于SS pro有一个非常明确的答案，我想抛出一些关于Web API的答案

Web API

Pro’s:

在你的项目中免费使用(前提是你有一个允许商业使用的VS许可证) 微软和所有网站都提供了非常高水平的免费支持，包括StackOverflow.com。 快速集成其他微软技术堆栈，如ASP。NET MVC在微软商店中非常流行 在Microsoft堆栈中内置了对RESTful身份验证和授权的支持

反对:

不支持SOAP

辅助的好处

(请随时在下面留下评论，补充为什么Web API有好处或有利弊，我可以补充)

作为ServiceStack的客户，对我来说最重要的是ServiceStack的专业知识。

https://github.com/ServiceStack/Issues/issues/606

所以。发现Bug，识别Bug，修复Bug。同样的一天。非凡的支持!

我用SS已经有一年了，一切都很好。 ORMLite是纯粹的魔法。我能够将一个糟糕的MySQL数据库重新映射到一个移动应用程序中。数据库没有变化，因为它是与另一个应用程序的php后端使用…

《Mythz》就是一个支持和解释的例子。它提升了我在应用程序设计和简单维护方面的知识。请尝试一下，你就会明白。

另外，不要将SS与WebAPI进行比较。这还不够，SS把更多的东西带到你的工具箱里。ServiceStack。文本也是一个很好的自动工具。

需要考虑一个新的主要差异——从v4开始ServiceStack不再免费使用。既然关于SS pro有一个非常明确的答案，我想抛出一些关于Web API的答案

Web API

Pro’s:

在你的项目中免费使用(前提是你有一个允许商业使用的VS许可证) 微软和所有网站都提供了非常高水平的免费支持，包括StackOverflow.com。 快速集成其他微软技术堆栈，如ASP。NET MVC在微软商店中非常流行 在Microsoft堆栈中内置了对RESTful身份验证和授权的支持

反对:

不支持SOAP

辅助的好处

(请随时在下面留下评论，补充为什么Web API有好处或有利弊，我可以补充)

关于ServiceStack我真的不能说太多，但是Web API有很多很棒的特性，目前是版本2。

你可以用Web API做一些事情:

OWIN应用程序中的自宿主(即在任何地方运行)。 完全支持async和await。 优秀的默认模板和大量的开源示例。 使用优秀的Json。Net JSON序列化器。 默认为Rest-ish(你必须自己做超媒体)。 和更多的……

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

ServiceStack从2008年开始就作为一个oss运行的项目，其目标只有一个，那就是促进正确设计和实现无摩擦的远程服务。

简洁优雅的设计

为了追求最终的简单性，它围绕着一个简单而优雅的核心构建——它的大多数功能自然地绑定到你的模型，而不是你的控制器——这就是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的不同之处在于它鼓励REST-ful API设计。至于这两个之间的例子，这是我所知道的唯一一个用ServiceStack和WebApi编写的相同服务的例子。

远程服务最佳实践

ServiceStack主要关注简单性、性能和促进web/远程服务最佳实践，围绕采用Martin fowler的远程服务设计模式，尽可能采用惯用的c#:

Facade模式——建议在跨进程边界通信时使用批处理的粗粒度接口。 DTO模式(MSDN)——指定使用特殊用途的poco来生成web服务响应的有线格式。 网关模式(MSDN)用于封装客户端网关/ DTO模型和服务接口层之间的客户端和服务器通信。

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

增强您的服务

ServiceStack web服务的核心是一个无依赖和自动连接的纯c# IService<T>接口，它让你完全自由地用自己的请求和响应dto定义web服务契约，使用干净的POCOs——使ServiceStack的API实际上是不可见的和非侵入性的，也就是说，提取你的c#服务逻辑并在ServiceStack主机之外运行它是很简单的。

这个要点是一个很好的例子，说明你在ServiceStack中只用一个c# .cs类就能得到什么:

所有已注册格式的元数据页 带有指向wsdl、xsd和c#客户端示例的链接 人性化友好的HTML报表视图 一个独立的html页面快照(即没有外部引用)。包括嵌入式JSON web服务响应-允许编程访问数据快照。 内置迷你分析器(优秀的MVC迷你分析器的端口) 包括Sql剖析 JSON/JSONP, XML, JSV, CSV和SOAP端点

RestServiceBase和ServiceBase类旨在托管您的自定义c#逻辑，以尽可能最大限度地重用，例如，它的dto优先设计简单地允许延迟和代理执行，其中您的相同c#服务也可以托管和执行在MQ主机中，这是当您注册一个IMessageService，如redmq主机，并通过/ asynconway端点调用您的服务时所发生的情况(即在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对象->序列化为响应内容类型 HttpResult, HttpError, CompressedResult (IHttpResult)用于自定义HTTP响应

以下类型不进行转换，直接写入响应流:

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

自定义HTTP报头支持的一个例子可以从这个CORS示例中看到，您可以在全局或每个服务的基础上配置HTTP报头。

HTML支持

ServiceStack中有多个返回HTML的选项，这里将详细解释。

包括。net最快的文本和二进制序列化器

弹性和快速的序列化器在API中是最重要的，以确保快速的响应时间和一个不破坏现有客户端的可版本的API，这就是为什么ServiceStack包含了。net最快的文本序列化器，带有NuGet选项，以启用@marcgravell的协议缓冲区(。NET最快的二进制序列化器)。

ServiceStack的文本序列化器非常有弹性，可以承受极端的版本控制而不会出错。

无摩擦的开发体验端到端

ServiceStack的自定义特性允许快速、类型化、简洁的端到端web服务API，并内置对Sync/Async c# /的支持。NET和Async Silverlight客户端，无需任何代码生成:

同步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 ServiceClients共享相同的接口，这使得它们具有高度的可测试性和可切换性，以至于您可以使用相同的单元测试，也可以作为XML、JSON、JSV、SOAP集成测试。

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

在提供无摩擦和干净的开发体验的使命中，ServiceStack还包括了内置的类型化验证和错误处理，其中抛出c#异常或使用其内置的Fluent验证为客户端提供了结构化的、易于在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，以取代其瘫痪的会话和缓存xml拖累的ASP。NET提供了自己的ICacheClient和ISession api的干净和无依赖的实现。

ServiceStack还包括一个更新、更清晰的认证和自动化提供程序模型，内置了许多不同的AuthProviders:

凭据-通过发布到/auth/凭据服务，使用用户名/密码凭据进行身份验证 基本认证-允许用户使用基本认证进行认证 Twitter OAuth -允许用户在Twitter上注册和认证 Facebook OAuth -允许用户注册和认证Facebook

认证模块是完全可选的，是建立在干净的ICacheClient / ISession api和OrmLite上，它允许你的会话存储在内存，Redis或Memcached和你的UserAuth信息保存在OrmLite支持的RDBMS的SQLServer, MySql, PostgreSQL, Sqlite以及Redis数据存储或InMemory(对开发/测试有用)。

伟大的文档

ServiceStack有很好的文档，关于该框架的大部分信息都托管在GitHub wiki上。框架的其他部分(例如Serializers, Redis, OrmLite)的文档可以在servicestack.net/docs/上找到

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

除了以上内容外，谷歌集团还包含了大量的信息，该集团近年来已经扩大了相当大的规模。

到处跑

ServiceStack是一个运行在ASP上的。net 3.5框架。NET和HttpListener托管，可以托管在。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有单核细胞

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

使用开源开发模型开发

ServiceStack是开源开发模型的坚定信徒，它是在开放环境中积极开发的，并且自成立以来一直在自由的OSS许可证(New BSD)下托管。到今天为止，它已经收到了超过47名开发人员的贡献，目前它在GitHub上排名第三。

缺点

我相信最大的缺点是大多数其他OSS . net项目都不是由微软开发的(甚至不是一个可用的选项)。这意味着它很少是评估框架时的首选。大多数采用者只会把ServiceStack作为最后的手段来评估，他们要么对WCF强加的摩擦和脆弱感到沮丧，要么对首选的Microsoft Stack的性能感到沮丧。

反馈和社区资源

ServiceStack已经得到了很好的接受，大多数人都提供了积极的反馈，他们通过邮件组中的积极情绪来评估它。今年，@ServiceStack推特账户一直在跟踪其收藏夹中的提及和反馈。

社区资源wiki页面是一个很好的地方，可以找到更多关于ServiceStack的链接，包括Blog Posts、Pod Casts、presentation、gist等。