Answers:
它们具有非常相似的用例，作为ServiceStack项目的首席维护者，我对ServiceStack的优势以及基于消息的设计的许多自然优势有着深刻的了解。
ServiceStack从2008年开始就作为OSS运行的项目而成立，其目标是促进正确设计和实施无摩擦远程服务。
为了追求极致的简单性，它以简单而优雅的核心为基础 -大部分功能自然绑定到您的模型，而不是您的控制器-WebApi正是MVC所做的（以及Microsoft生产的所有其他Web Service Framework） ）。
采用基于消息的设计为远程服务提供了一种更好的方法，因为它们促进了更可扩展，更不易碎的服务，简化了访问和呼叫方式，并包含了许多其他免费的自然收益。
作为一项核心任务，我们在每个阶段都与复杂性作斗争，以保持不可见和非侵入性的API，并避免引入当今.NET或Web服务开发人员尚不熟悉的任何新概念或人工构造。
例如，您的IService<T>服务实现只是具有自动关联的标准C＃类。轻薄包装器用于围绕核心运行时IHttpRequest和IHttpResponse类型提供一致且统一的API 。它们还允许访问基础ASP.NET或HttpListener的Request和Response类，因此在使用ServiceStack时永远不会受到限制。
这是ServiceStack和WCF推广的对比API样式的简要概述。WebApi与WCF不同，它鼓励REST-ful API设计。至于2之间的示例，这是我仅有的使用ServiceStack和WebApi编写的相同服务的示例。
ServiceStack主要关注于简单性，性能以及促进Web /远程服务的最佳实践，该实践的重点是尽可能地将Martin Fowlers远程服务设计模式包含在C＃中：
在外观模式 -当你永远跨进程边界的沟通提示的batchful，粗粒度的接口使用。
这些模式确保了关注点的清晰分离和无摩擦的迭代开发经验。
ServiceStack Web服务的核心围绕一个无依赖关系和自动连线的纯C＃IService<T>接口，该接口使您可以完全自由地使用干净的POCO与自己的请求和响应DTO定义Web服务合同-使ServiceStack的API几乎不可见且不可见侵入式，即提取C＃服务逻辑并在ServiceStack主机外部运行它很简单。
这个要点很好地说明了在ServiceStack中仅使用1个C＃.cs类所得到的结果：
RestServiceBase和ServiceBase类旨在承载您的自定义C＃逻辑，以实现最大程度的潜在重用。例如，其DTO优先设计可以轻松地进行延迟和代理执行，而您的相同C＃服务也可以在MQ主机中托管和执行。当您注册IMessageService类似RedisMQ的主机并通过/asynconeway端点调用服务时（即client.SendOneWay()在C＃客户端中），会发生这种情况
您还可以使用该base.ResolveService<T>()方法轻松委托和创建组合服务，该方法返回所选服务的自动关联实例，如Nortwind CustomerDetails Service示例所示：
var ordersService = base.ResolveService<OrdersService>();
var ordersResponse = (OrdersResponse)ordersService.Get(
new Orders { CustomerId = customer.Id });
大多数情况下，ServiceStack会按预期序列化大多数C＃对象-这是可能的返回类型列表（来自此答案）：
以下类型不会转换，而是直接写入响应流：
通过此CORS示例可以看到自定义HTTP标头支持的示例，您可以在其中全局配置或基于每个服务配置HTTP标头。
在ServiceStack中有多个用于返回HTML的选项，这里将详细说明。
弹性和快速串行是最重要的API中，以确保快速的响应时间，并且不会破坏现有的客户端这就是为什么ServiceStack包括一个版本化API 用于.NET最快的文本串行用的NuGet选项来启用@marcgravell的协议缓冲区（.NET最快的二进制串行器）。
ServiceStack的文本序列化程序非常灵活，可以承受极端版本控制而不会出错。
ServiceStack自以为是的特性允许快速，类型化，简洁的Web服务API端到端，并内置对Sync / Async C＃/。NET和Async Silverlight客户端的内置支持，而无需任何代码源：
var response = client.Send<HelloResponse>(new Hello { Name = "World!" });
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 ServiceClient共享相同的接口，这使它们具有高度的可测试性和可交换性，以至于您可以具有相同的单元测试，并且还可以用作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示例项目提供了一个很好的示范。
该ServiceStack MVC的PowerPack重新写入，并修复了大量的ASP.NET和MVC苦恼的与替代其沉重的会议和缓存XML，ASP.NET拖累商有自己的清洁，无依赖，实现ICacheClient和的ISession的API。
ServiceStack还包括一个更新，更清洁的身份验证和授权提供程序模型，其中内置了许多不同的AuthProviders：
身份验证模块是完全可选的，基于干净的ICacheClient / ISession API和OrmLite构建，该模块允许将会话存储在内存，Redis或Memcached中，并且您的UserAuth信息持久存储在OrmLite支持的RDBMS的SQLServer，SQL Server，MySql，PostgreSQL，Sqlite中，以及Redis数据存储区或InMemory（用于开发/测试）。
关于ServiceStack的文档非常齐全，其中有关该框架的大多数信息都托管在GitHub Wiki上。可以在servicestack.net/docs/上找到框架其他部分的文档（例如，序列化器，Redis，OrmLite）。
该ServiceStack.Examples项目提供了所有ServiceStack的现场演示和入门模板的源代码，而SocialBoostsrapApi项目提供开发Backbone.js的单页应用与ServiceStack和MVC基于Twitter的引导模板的一个很好的起点。
除上述内容外，Google小组中还包含大量的信息，近年来该小组的信息已大大扩展。
ServiceStack是一个可在ASP.NET和HttpListener主机上运行的.NET 3.5框架，并且可以托管在.NET或Mono上（琐事：www.servicestack.net由CentOS / Mono提供支持）。这允许您将ServiceStack Web服务托管在以下任一主机上：
ServiceStack坚信开放源代码开发模型，该模型在公开场合一直在积极开发，并且自成立以来就一直以自由OSS许可证（New BSD）托管。截止到今天，它已经收到来自47个开发人员的捐款，目前它是GitHub上第三大受关注的C＃项目。
我认为最大的缺点是对于大多数其他未由Microsoft开发（或什至列为可用选项）的OSS .NET项目都是相同的。这意味着在评估框架时，它很少是首选。大多数采用者只会将ServiceStack视为万不得已的方法，因为他们要么对WCF的摩擦和脆弱性，要么对首选Microsoft Stack的性能感到沮丧。
大多数人都认为ServiceStack受到好评，并得到了邮件组中积极情绪的认可，大多数人对此给予了积极评价。截至今年，@ ServiceStack Twitter帐户一直在其收藏夹中跟踪提及和反馈。
该社区资源 wiki页面是一个好地方，以了解更多有关ServiceStack在链接到博客，波德广播，简报，要旨，更野性。
有一个新的主要区别需要考虑-ServiceStack从v4开始不再免费使用。 既然SS专业人士的回答很明确，我想为Web API扔掉一对
专业人士：
骗局：
辅助福利
（请随意在下面留下评论，以补充为什么我可以添加Web API的优点或优点/缺点）
关于ServiceStack，我不能说太多，但是Web API具有很多出色的功能，并且当前版本为2。
您可以使用Web API进行的一些操作：
async和await。作为ServiceStack的客户，这对我来说最重要的是ServiceStack的专业人士。
https://github.com/ServiceStack/Issues/issues/606
所以。发现错误，确定错误，已修复错误。同一天。非凡的支持！