ServiceStack与ASP.Net Web API
我想编写一个新的REST风格API，并且已经看过ServiceStack并且非常喜欢它。 不过，我已经看到，微软已经发布了ASP.Net Web API项目作为新的MVC 4测试版的一部分。 有没有人看过新的Web API项目？ 你能给每个系统的优点/缺点吗？
作为ServiceStack项目的主要维护人员，他们有非常相似的用例，我对ServiceStack的优势以及基于消息的设计的许多自然优势有了很好的了解。
自2008年以来，ServiceStack一直是OSS运行的项目，其唯一目标就是促进无摩擦远程服务的正确设计和实施。
简单和优雅的设计
在追求极致简洁的同时，它围绕着一个简单而优雅的内核构建 - 其大部分功能自然地绑定到您的模型 ，而不是您的控制器 - 这正是MVC，WebApi所做的（以及Microsoft生产的其他任何Web服务框架）。
采用基于消息的设计为远程服务提供了一种卓越的方法，因为它们可以促进更多的可扩展性和更少的脆弱服务，简化访问和调用模式，并且包含许多免费获得的其他自然益处。
作为一项核心使命，我们在每个阶段都努力争取复杂性，旨在保持一种无形的非侵入式API，并避免引入当今.NET或Web服务开发人员不熟悉的任何新概念或人为构造。
作为一个例子，您的IService<T>服务实现只是一个标准的C＃类，具有自动连接的依赖关系。 使用轻量级和轻量级的包装来围绕核心运行时IHttpRequest和IHttpResponse类型提供一致且统一的API。 他们还允许访问底层的ASP.NET或HttpListener的请求和响应类，以便在使用ServiceStack时永远不会受到限制。
与WCF和WebApi相对照
以下是ServiceStack和WCF推广的对比API样式的简要概述。 WebApi与WCF的不同之处在于它鼓励REST-ful API设计。 至于2之间的示例，这是我用ServiceStack和WebApi编写同一服务的唯一已知示例。
最佳做法远程服务
ServiceStack主要关注简单性，性能和促进以尽可能惯用C＃的Martin Fowlers远程服务设计模式为中心的Web /远程服务最佳实践：
Facade模式 - 当您跨越流程边界进行通信时，建议使用批处理，粗粒度的界面。
DTO模式（MSDN） - 指定使用专用POCO来生成Web服务响应的有线格式。
网关模式（MSDN）封装客户端网关/ DTO模型和服务接口层之间的客户端和服务器通信。
这些模式确保了关注的清晰分离和无摩擦的迭代开发体验。
增强您的服务
其核心的ServiceStack Web服务主要围绕无依赖和自动连接的纯C＃ IService<T>接口，它使您可以完全自由地使用干净的POCO定义您的Web服务合同，并使用您自己的请求和响应DTO - 呈现ServiceStack的API实际上是不可见的和非侵入性的，即提取C＃服务逻辑并在ServiceStack主机之外运行它是微不足道的。
这个要点就是你在ServiceStack中只用1个C＃.cs类获得的好例子：
RestServiceBase和ServiceBase类旨在托管您的自定义C＃逻辑，以尽可能实现最大潜力重用，例如，其DTO优先设计允许延迟和代理执行，您的相同C＃服务也可以在MQ主机中托管和执行当您注册IMessageService如RedisMQ主机）并通过/asynconeway端点（即C＃客户端中的client.SendOneWay()调用您的服务时会发生什么情况。
您还可以使用base.ResolveService<T>()方法轻松委派和创建组合服务，该方法返回所选服务的自动连线实例，如Nortwind CustomerDetails服务示例中所示：
var ordersService = base.ResolveService<OrdersService>();
var ordersResponse = (OrdersResponse)ordersService.Get(
new Orders { CustomerId = customer.Id });
返回纯C＃对象
大多数情况下，ServiceStack会按预期序列化大多数C＃对象 - 下面是可能的返回类型列表（来自此答案）：
以下类型不会被转换并直接写入响应流：
此CORS示例可以看到自定义HTTP头支持的示例，您可以在其中全局或基于每个服务配置HTTP头。
HTML支持
在ServiceStack中有多个选项可用于返回HTML，这在此处详细介绍。
包括用于.NET的最快文本和二进制序列化器
Resilient和快速序列化器在API中最重要，以确保快速响应时间以及不会破坏现有客户端的可版本化API，这就是为什么ServiceStack包含用于.NET的最快文本序列化器以及NuGet选项以启用@ marcgravell的协议缓冲器.NET最快的二进制串行器）。
ServiceStack的文本串行器非常有弹性，可以承受极端的版本控制而不会出错。
无摩擦开发体验端到端
ServiceStack的自以为是的特性允许通过内置的Sync / Async C＃/ .NET和Async Silverlight客户端而不需要任何代码生成端对端的快速，类型化，简洁的Web服务API：
同步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＃Exception或使用其内置的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：
认证模块完全是可选的，并且建立在干净的ICacheClient / ISession API和OrmLite上，它允许您的会话存储在内存，Redis或Memcached中，并且您的UserAuth信息保存在OrmLite支持的SQLServer，MySql，PostgreSQL，Sqlite的RDBMS中以及Redis数据存储或InMemory（用于开发/测试）。
很棒的文档
ServiceStack在有关框架的大部分信息托管在GitHub wiki上的文档中都有很好的记录。 框架其他部分的文档（例如Serializers，Redis，OrmLite）可以在servicestack.net/docs/上找到
ServiceStack.Examples项目提供了所有ServiceStack的实时演示和入门模板的源代码，而SocialBoostsrapApi项目为开发基于Twitters Bootstrap模板的ServiceStack和MVC开发Backbone.js单页应用程序提供了一个很好的起点。
除上述之外，Google集团内部还包含了宝贵的信息，近年来这些信息已经大大扩展。
随处运行
ServiceStack是一个运行在ASP.NET和HttpListener主机上的.NET 3.5框架，可以在.NET或Mono上托管（琐事：www.servicestack.net由CentOS / Mono支持）。 这允许您的ServiceStack Web服务托管在以下任一项上：
Windows与.NET 3.5和4.0
带Mono的Linux / OSX
采用开源开发模式开发
ServiceStack是开源开发模型的坚定信徒，开源开发模式是开源开发模式，自开放以来，始终由自由的OSS许可证（New BSD）托管。 截至今天，它已收到来自超过47位开发人员的贡献，目前它已成为GitHub上第三大受关注的C＃项目。
缺点
我认为对于大多数其他OSS .NET项目来说，最大的缺点是它没有被微软开发（甚至没有列为可用选项）。 这意味着它在评估框架时很少成为首选。 大多数采用者只会评估ServiceStack作为最后的手段，他们要么因WCF的强制摩擦和脆弱性或首选Microsoft Stack的性能而感到沮丧。
反馈和社区资源
ServiceStack得到了很好的回应，大多数人对邮件组的积极情绪进行了评估，因此得到了积极的反馈。 从今年开始，@ServiceStack Twitter帐户一直在收藏夹中跟踪提及和反馈。
社区资源wiki页面是一个很好的地方，可以通过指向博客文章，Pod演绎，演示文稿，Gist等链接了解更多有关ServiceStack的信息。
有一个新的主要区别需要考虑 - 从第4版开始， ServiceStack不再可以免费使用。 由于对SS Pro有一个非常明确的答案，我想为Web API抛出一对夫妇
Web API
Pro's：
Con's：
辅助福利
（请随意留下评论，以增加为什么Web API有益处或者我可以添加优点/缺点）
我无法对ServiceStack说得太多，但Web API有很多很棒的功能，目前版本为2。
您可以使用Web API执行的一些操作：
async和await 。 上一篇: ServiceStack vs ASP.Net Web API
下一篇: Using Chrome's Element Inspector in Print Preview Mode?