ServiceStack与ASP.Net Web API

ServiceStack vs ASP.Net Web API

我想编写一个新的REST风格的API，并研究了ServiceStack，非常喜欢它。但是，我看到微软已经发布了ASP.NET Web API项目，作为新的MVC 4测试版的一部分。有人看过新的Web API项目吗？你能给出每个系统的优缺点吗？

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

ServiceStack自2008年以来一直是一个OSS运行项目，其目标是促进无摩擦远程服务的正确设计和实现。好的。简洁典雅的设计

在追求终极简单性的过程中，它围绕着一个简单而优雅的核心构建——它的大部分功能自然地绑定到您的模型，而不是您的控制器——这正是MVC、WebAPI所做的(以及微软生产的所有其他Web服务框架)。好的。

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

作为一项核心任务，我们在每个阶段都与复杂性作斗争，目的是保持一个不可见的、非侵入性的API，避免引入任何新的概念或人工构造，而这些概念或人工构造目前对.NET或Web服务开发人员并不熟悉。好的。

例如，您的IService服务实现只是一个具有自动连线依赖性的标准C类。薄型和轻型包装器用于围绕核心运行时ihtprequest和ihtprespons类型提供一致和统一的API。它们还允许访问底层的ASP.NET或httpListener的请求和响应类，这样在使用ServiceStack时就不会受到限制。好的。与WCF和WebAPI相比

以下是ServiceStack和WCF所提升的对比API样式的简要概述。WebAPI不同于WCF，因为它鼓励RESTfulAPI设计。对于2之间的示例，这是我在ServiceStack和WebAPI中使用相同服务的唯一已知示例。好的。最佳实践远程服务

ServiceStack主要关注简单性、性能和推广Web/远程服务最佳实践，其核心是尽可能采用惯用的C中的Martin Fowlers远程服务设计模式：好的。

facade模式——当您跨越流程边界进行通信时，它建议使用批处理的粗粒度接口。好的。
dto模式(msdn)——指示使用特殊用途的poco来生成Web服务响应的有线格式。好的。
网关模式(msdn)，用于封装客户机网关/dto模型和服务接口层之间的客户机和服务器通信。好的。

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

核心的ServiceStack Web服务以无依赖性和自动连接的纯C IService接口为中心，该接口允许您完全自由地使用干净的POCOS定义Web服务合同，并使用自己的请求和响应DTO—呈现ServiceStack的API实际上是不可见的和非侵入性的，即，提取您的C服务逻辑，并在服务堆栈主机外运行它。好的。

这个要点是一个很好的例子，说明在ServiceStack中只使用1个c.cs类可以得到什么：好的。

所有已注册格式的元数据页
- 链接到wsdls、xsds和c客户机示例
人性化的HTML报表视图
- 一个独立的HTML页面快照(即没有外部引用)。包括嵌入式JSON Web服务响应-允许编程访问数据快照。
内置迷你探查器(优秀MVC迷你探查器的端口)
- 包括SQL分析
JSON/JSONP、XML、JSV、CSV和SOAP端点

RestServiceBase和ServiceBase类旨在承载您的定制C逻辑，以尽可能地最大限度地重用它，例如，它的DTO-First设计琐碎地允许延迟和代理执行，在这种情况下，您的同一C服务也可以在MQ主机中承载和执行，这就是当您注册像redi一样的IMessageService时所发生的情况SMQ通过/asynconeway端点(即c客户机中的client.SendOneWay()端点)承载并呼叫您的服务。好的。

您还可以使用base.ResolveService()方法轻松地委托和创建复合服务，该方法返回所选服务的自动连线实例，如nortwind customerdetails服务示例所示：好的。

1
2
3

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

返回普通C对象

对于大多数情况，ServiceStack将按预期对大多数C对象进行序列化-以下是可能的返回类型列表(来自此答案)：好的。

任何DTO对象->序列化为响应ContentType
用于自定义HTTP响应的httpresult、httperror、compressedresult(ihtpresult)

以下类型不会被转换并直接写入响应流：好的。

弦
河流
特写作家
字节[]—具有应用程序/八位字节流内容类型。

这个CORS示例可以看到自定义HTTP头支持的一个示例，在这个示例中，您可以全局或按服务配置HTTP头。好的。HTML支持

在ServiceStack中有多个返回HTML的选项，在这里详细解释。好的。包括最快的.NET文本和二进制序列化程序

在API中，弹性和快速序列化程序是确保快速响应时间的主要因素，而可版本化的API不会破坏现有客户机，因此ServiceStack为.NET提供了最快的文本序列化程序，并具有启用@MarcGravell协议缓冲区的nuget选项(.net最快的二进制序列化程序)。好的。

ServiceStack的文本序列化程序具有很强的弹性，能够承受极端的版本控制而不会出错。好的。无摩擦开发体验端到端

ServiceStack的固有特性允许快速、类型化、简洁的Web服务API端到端，内置对同步/异步C/.NET和异步Silverlight客户端的支持，无需任何代码生成：好的。同步C示例

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

异步C示例

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

由于它只返回纯JSON，因此它也被其他HTTP客户机(如使用jquery的JS客户机示例)所占用：好的。

1
2
3

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

高度可测试性

所有C/.NET服务客户机共享相同的接口，这使得它们具有高度的可测试性和可交换性，在这里您可以进行相同的单元测试，还可以作为XML、JSON、JSV、SOAP集成测试。好的。丰富的验证和错误处理内置

ServiceStack的使命是提供一种免费和干净的开发体验，它还包括类型化验证和错误处理内置，其中抛出C异常或使用其内置的Fluent验证为客户机提供结构化的、类型化的错误，这些错误很容易在Web服务客户机上访问，例如：好的。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

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的AIL，并替换了其严重的会话，并用自己的干净的、无依赖性的iCacheClient和ISession API实现缓存XML妨碍的ASP.NET提供程序。好的。

ServiceStack还包括一个更新的、更清晰的身份验证和自动化提供程序模型，内置了许多不同的AuthProvider：好的。

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

身份验证模块是完全可选的，它建立在干净的icacheclient/isession API和ormlite之上，允许您的会话存储在内存、redis或memcached中，并且您的用户身份验证信息保存在ormlite支持的rdbms(sqlserver、mysql、postgresql、sqlite以及redis数据存储或in memory)中(对dev/test有用NG)。好的。很棒的文档

ServiceStack有很好的文档记录，其中关于框架的大部分信息都托管在Github wiki上。可在servicestack.net/docs上找到框架其他部分(如序列化程序、redis或Lite)的文档。/好的。

ServiceStack.Examples项目提供了所有ServiceStack的实时演示和启动模板的源代码，而SocialBoostsRapapi项目提供了一个基于twitters引导模板开发带有ServiceStack和MVC的backbone.js单页应用程序的良好起点。好的。

除此之外，谷歌集团还拥有丰富的信息资源，近年来，谷歌集团的规模已大幅扩大。好的。处处奔跑

ServiceStack是一个.NET 3.5框架，运行在ASP.NET和HTTPListener主机上，可以托管在.NET或Mono上(trivia:www.serviceStack.net由CentOS/Mono提供支持)。这允许您的ServiceStack Web服务托管在以下任一位置：好的。带有.NET 3.5和4.0的Windows

IIS 5/6/7(使用IHttphandler)
与.NET WebDevServer
控制台应用程序或Windows GUI
视窗服务

带有mono的Linux/OSX

阿帕奇+莫诺
nginx+单速CGI
XSP
控制台应用程序

使用开源开发模型开发

ServiceStack是开源开发模式的坚定拥护者，它是在开放环境中积极开发的，并且自成立以来一直在自由的OSS许可(新的BSD)下托管。到今天为止，它已经收到了超过47个开发人员的贡献，目前它在Github上排名第三。好的。缺点

我认为大多数其他OSS.NET项目的最大缺点是相同的，因为它不是由微软开发的(甚至被列为可用选项)。这意味着在评估框架时，它很少是第一选择。大多数采用者只会将ServiceStack作为最后的手段，他们要么对WCF的强摩擦和脆弱性感到沮丧，要么对首选Microsoft堆栈的性能感到沮丧。好的。反馈和社区资源

ServiceStack得到了很多好评，大多数人都提供了正面反馈，他们认为邮件组的正面情绪可以看出这一点。截至今年，@servicestack twitter账户一直在追踪其最喜爱的评论和反馈。好的。

社区资源wiki页面是一个很好的地方，可以通过链接到博客文章、播客、演示、要点等来了解更多关于服务堆栈的信息。好的。好啊。