ServiceStack VS ASP.Net的Web API [英] ServiceStack vs ASP.Net Web API

问题描述

我想写一个新的REST风格的API，并看着ServiceStack和很喜欢它。不过，我已经看到，微软已经发布了ASP.Net的Web API项目作为新的MVC 4测试版的一部分。有没有人看着新的Web API项目？你可以给每个系统的任何优点/缺点？

I want to write a new REST style API and have looked at ServiceStack and quite like it. However, I have seen that Microsoft has released the ASP.Net Web API project as part of the new MVC 4 beta. Has anyone looked at the new Web API project? Can you give any pros/cons of each system?

推荐答案

他们有非常类似用途的情况下，作为牵头维护者的的 ServiceStack项目我有一个很好的洞察ServiceStack的优势和的其基于消息的设计的许多自然好处。

They have very similar use-cases, as the lead maintainer for the ServiceStack project I have a good insight into ServiceStack's advantages and the many natural benefits of its message-based design.

ServiceStack已经出现自2008年以来从它与促进无摩擦的远程服务的正确设计和实现的一个目标开始的OSS运行项目。

ServiceStack has been around since 2008 as an OSS-run project from its inception with a single goal of promoting the correct design and implementation of friction-free remote services.

在其追求极致简约，它的周围一个简单而优雅的核心 - 与它的大部分功能自然结合的您的模型，不是你的控制器 - 这就是MVC，做的WebAPI（以及其他所有的Web服务框架微软已经产生）

In its pursuit for ultimate simplicity, it's built around a simple and elegant core - with most of its features naturally binding to your models, not your controllers - which is what MVC, WebApi does (as well as every other Web Service Framework Microsoft has produced).

采用一个基于消息的设计提供了远程服务优越的做法，他们提倡更多的可扩展性和不易碎的服务，简化了访问和调用模式，的包含许多其他自然好处，你得到免费优势 - 基于消息的Web服务的 - 。

Adopting a message-based design offers a superior approach for remote services, in that they promote more extensible and less brittle services, simplifies access and calling patterns, and contain many other natural benefits you get for free.

作为核心任务，我们在每一个阶段打的复杂性，旨在保持一个无形的，非侵入性的API，避免引入任何今天是不是已经熟悉的.NET或Web服务开发新的概念或人工构造。

As a core mission, we fight complexity at every stage, aiming to keep an invisible and non-intrusive API and avoid introducing any new concepts or artificial constructs that aren't already familiar to .NET or web service developers today.

作为一个例子你的 IService＆LT; T＆GT; 服务实现是一个标准的C＃类，支持自动布线的依赖。薄且重量轻的包装被用于提供围绕核心运行时<一个一致的和统一的API href=\"https://github.com/ServiceStack/ServiceStack/blob/master/src/ServiceStack.Interfaces/ServiceHost/IHtt$p$pquest.cs\"相对=nofollow> IHtt prequest 和<一个href=\"https://github.com/ServiceStack/ServiceStack/blob/master/src/ServiceStack.Interfaces/ServiceHost/IHtt$p$psponse.cs\"相对=nofollow> IHtt presponse 类型。他们还允许访问底层ASP.NET或的HttpListener的请求和响应类，所以你永远使用ServiceStack时受到限制。

As an example your IService<T> service implementation is just a standard C# class with auto-wired dependencies. Thin and lightweight wrappers are used to provide a consistent and unified API around the core run-time IHttpRequest and IHttpResponse types. They also allow access to underlying ASP.NET or HttpListener's Request and Response classes so you're never restricted when using ServiceStack.

下面是那 ServiceStack和WCF促进对比鲜明的API风格的简要概述。的WebAPI是不同的，以WCF，它鼓励REST-FUL API设计。而对于2之间的例子，这是唯一已知的例子，我有写在这两个 ServiceStack和的WebAPI

Here's a brief overview of the contrasting API styles that ServiceStack and WCF promote. WebApi is different to WCF in that it encourages REST-ful API design. As for examples between the 2, this is the only known example I have with the same service written in both ServiceStack and WebApi.

ServiceStack有一个主要专注于简单性，性能和促进周围的惯用C＃拥抱马丁福勒斯远程服务的设计模式尽可能为中心的Web /远程服务的最佳实践：

ServiceStack has a primary focus on simplicity, performance and in promoting web/remote service best-practices centered around embracing Martin Fowlers remote-service design patterns in as idiomatic C# as possible:

• 借助外观模式 - 这表明的batchful，粗粒界面的使用当你永远跨进程边界通信。

• The Facade Pattern - Which suggests the usage of batchful, coarse-grained interfaces when ever you communicate across process boundaries.

借助 DTO模式（的 MSDN ） - 口述使用专用的波苏斯来生成您的Web服务响应的有线格式

The DTO pattern (MSDN) - Dictating the use of special-purpose POCOs to generate the wire format of your web services responses.

借助网关模式（的 MSDN ）封装客户端网关/ DTO模式和服务接口层之间的客户端和服务器的通信。

The Gateway Pattern (MSDN) to encapsulate your client and server communications between the Client Gateway / DTO models and Service Interface tiers.

这些图案确保清楚的关注点分离和无摩擦的迭代开发的经验。

These patterns ensure a clean separation of concerns and a friction-free iterative dev experience.

的核心是ServiceStack Web服务是围绕一个免费的依赖性和自动有线纯C＃ IService＆LT中心; T＆GT; 界面，让您完全自由地定义你的网络用自己的请求和响应使用干净的DTO波苏斯服务合同 - 渲染ServiceStack的API几乎看不见和非侵入性的，也就是说，它是微不足道的提取您的C＃业务逻辑和运行它ServiceStack主机之外

A ServiceStack web service at its core is centered around a dependency-free and auto-wired pure C# IService<T> interface that gives you complete freedom to define your web service contract with your own Request and Response DTOs using clean POCOs - rendering ServiceStack's API practically invisible and non-invasive, i.e. it's trivial to extract your C# services logic and run it outside of a ServiceStack host.

这要点是你与仅有1 C＃的.cs在ServiceStack 类得到的一个很好的例子：

This gist is a good example of what you get with just 1 C# .cs class in ServiceStack:

• 元数据页面所有注册格式
  
  
  • 链接到的WSDL，XSD文件和C＃示例客户端
  
  
  
  
  • 一个自包含的HTML网页快照（即没有外部裁判）。包括嵌入式JSON Web服务响应 - 允许数据快照的编程访问
  。
  
  
  
  • 包含SQL事件探查
  
  

  该RestServiceBase和ServiceBase类是为了承载您定制的C＃逻辑最大潜力再利用成为可能，例如，它的DTO为先的设计平凡允许延期和代理执行您的同一个C＃服务，也可以托管在一个MQ主机也就是当您注册一个 IMessageService 一样会发生什么执行 RedisMQ主机并通过调用您的服务 / asynconeway 终点（即 client.SendOneWay（）在C＃中的客户端）

  The RestServiceBase and ServiceBase classes are intended to host your custom C# logic for maximum potential re-use as possible, e.g. Its DTO-first design trivially allows for deferred and proxied execution where your same C# Service can also be hosted and executed in an MQ Host which is what happens when you register an IMessageService like the RedisMQ host and call your service via the /asynconeway endpoint (i.e. client.SendOneWay() in C# Clients)

  您也可以轻松地委派并使用 base.ResolveService＆LT创建复合服务; T＆GT;（）方法，在看到它返回所选服务的自动有线实例在<一个href=\"https://github.com/ServiceStack/ServiceStack.Examples/blob/master/src/ServiceStack.Northwind/ServiceStack.Northwind.ServiceInterface/CustomerDetailsService.cs#L22\"相对=nofollow> Nortwind为CustomerDetails服务例如：

  You can also easily delegate and create composite services using the base.ResolveService<T>() method which returns an auto-wired instance of the selected service as seen in the Nortwind CustomerDetails Service example:

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

  返回纯C＃对象

  对于大部分ServiceStack将系列化预期大多数C＃的对象 - 这里是可能的返回类型的列表（<一个href=\"http://stackoverflow.com/questions/6245616/does-servicestack-support-binary-responses/6249042#6249042\">from这个答案）：

  
  
  • 任何DTO对象 - >序列化到响应的ContentType
  
  
  • 的Htt presult，HTTPError这样，COM pressedResult（IHtt presult）定制HTTP响应
  
  

  以下类型不转换并获得直接写入响应流：

  The following types are not converted and get written directly to the Response Stream:

  
  
  • 字符串
  
  
  • 流
  
  
  • IStreamWriter
  
  
  • 字节[] - 与应用程序/八位字节流内容类型
  
  

  自定义HTTP的例子头的支持，可以通过这个CORS例子在这里您可以全局或每个服务的基础上配置HTTP头。

  An example of the Custom HTTP headers support can be seen by this CORS example where you can configure HTTP Headers globally or on a per-service basis.

  有在ServiceStack是<返回一个HTML多种选择href=\"http://stackoverflow.com/questions/8199493/is-it-possible-to-serve-html-pages-with-servicestack/8200056#8200056\">explained在这里详细的。

  There are multiple options for returning HTML in ServiceStack that is explained in detail here.

  弹性和快速序列化是最重要的API中，以确保快速响应时间，它不会破坏现有的客户端是一个多版本的API，为什么ServiceStack包含的文本最快串行针对.NET 用的NuGet选项启用的 @marcgravell 的 Protocol Buffers的（.NET最快的二进制串行器）。

  Resilient and fast serializers are of primary importance in an API to ensure fast response times and a versionable API which doesn't break existing clients which is why ServiceStack includes the fastest text serializers for .NET with a NuGet option to enable @marcgravell's Protocol Buffers (.NET's fastest binary serializer).

  ServiceStack文本序列化是非常有弹性，可以承受极端版本没有错误。

  ServiceStack's text serializers are very resilient and can withstand extreme versioning without error.

  ServiceStack的固执本性使得一个快速，打字，简洁的Web服务API终端到终端与内置的的同步/异步C＃/。NET 和异步的Silverlight 的客户没有任何code根：

  ServiceStack's opinionated nature allows for a fast, typed, terse web service API end-to-end with built-in support for Sync/Async C#/.NET and Async Silverlight clients without any code-gen:

  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客户端，例如消费 JS使用jQuery 客户端的例子：

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

  高度可测试

  所有的C＃/。NET ServiceClients分享这使他们高度可测试相同的接口和可交换的地步，你可以在相同的单元测试也充当<一个href=\"https://github.com/ServiceStack/ServiceStack/blob/master/tests/ServiceStack.WebHost.IntegrationTests/Tests/WebServicesTests.cs\"相对=nofollow> XML，JSON，JSV，SOAP集成测试。

  Highly testable

  All C#/.NET ServiceClients share the same interfaces which make them highly testable and swappable to the point where you can have the same unit test also serve as an XML, JSON, JSV, SOAP Integration Test.

  在其使命提供friciton自由和清洁开发经验，ServiceStack还包括输入验证和错误处理的内置在抛出C＃异常或使用其内置的验证流利为客户提供结构化，类型化的错误在Web服务客户端，如交通方便：

  In its mission to provide a friciton-free and clean dev experience, ServiceStack also includes typed validation and error handling built-in where throwing an C# Exception or using its built-in Fluent validation provides clients structured, typed errors easily accessible on web service clients, e.g:

  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表单字段与code一行。该 SocialBootstrapApi示例项目提供了一个很好的示范。

  To make it trivial to consume errors in JavaScript, you can use the lightweight ss-validation.js JavaScript library to trivially bind your response errors to your HTML form fields with a single line of code. The SocialBootstrapApi example project provides a good demo of this.

  借助 ServiceStack MVC的PowerPack 重新写入和修复了很多ASP的苦恼的的。 NET和MVC与替代它的<一个href=\"http://stackoverflow.com/questions/3629709/i-just-discovered-why-all-asp-net-websites-are-slow-and-i-am-trying-to-work-out\">crippling对话和缓存XML的拖累ASP.NET商有自己的清洁，无依赖，实现ICacheClient和的ISession的API。

  The ServiceStack MVC PowerPack re-writes and fixes a lot of the ails of ASP.NET and MVC with replacements for its crippling Session and Caching XML-encumbered ASP.NET providers with its own clean and dependency-free implementation of ICacheClient and ISession APIs.

  ServiceStack还包括新的和更清洁的认证和autorization提供者模型与许多不同AuthProviders的内置

  ServiceStack also includes a newer and cleaner authentication and autorization provider model with a number of different AuthProviders in-built:

  
  
  • 凭据 - 对于张贴到/认证/证书服务使用用户名/密码认证证书
  
  
  • 基本验证 - 允许用户使用基本身份验证验证
  
  
  • 的Twitter的OAuth - 允许用户注册，并与Twitter进行身份验证
  
  
  • 的Facebook的OAuth - 允许用户注册，并与Facebook验证
  
  

  认证模块是完全可选的内置在干净的ICacheClient / ISession的API和OrmLite，让您的会议将被存储在内存中，Redis的或Memcached的和你USERAUTH信息坚持OrmLite支持的RDBMS的SQLServer，MySQL和PostgreSQL中的时，SQLite以及Redis的数据存储或InMemory（用于开发/测试非常有用）。

  The Authentication module is entirely optional and is built-on the clean ICacheClient / ISession APIs and OrmLite which allows your Sessions to be stored in Memory, Redis or Memcached and your UserAuth info persisted in OrmLite's supported RDBMS's of SQLServer, MySql, PostgreSQL, Sqlite as well as Redis data-store or InMemory (useful for dev/testing).

  ServiceStack是非常有据可查的大多数关于框架的信息在 GitHub的维基。文档为框架的其他部分（如串行器，Redis的，OrmLite）可以在 servicestack.net/docs/ <找到/ A>

  ServiceStack is very well documented where most of the information about the framework is hosted on the GitHub wiki. Documentation for other parts of the framework (e.g. Serializers, Redis, OrmLite) can be found on servicestack.net/docs/

  借助 ServiceStack.Examples 项目提供了源$ C ​​$ C为所有ServiceStack的活演示和入门模板，同时在 SocialBoostsrapApi项目提供开发Backbone.js的单页应用程序与一个伟大的起点ServiceStack和MVC基于Twitter的引导模板。

  The ServiceStack.Examples Project provides the source code for all of ServiceStack's live demos and Starter Templates whilst the SocialBoostsrapApi project provides a great starting point of developing a Backbone.js Single Page App with ServiceStack and MVC based on Twitters Bootstrap template.

  在除上述信息的宝库是包含在谷歌集团一>已经在最近几年相当显着扩大。

  In addition to the above a treasure trove of information is contained within the Google Group which has expanded quite considerably in recent years.

  ServiceStack是一个.NET 3.5框架，在ASP.NET运行和的HttpListener主机，并且可以在任何.NET或单声道（琐事主办：的 www.servicestack.net 由CentOS的/单声道供电）。这使您的ServiceStack Web服务被托管或者：

  ServiceStack is a .NET 3.5 framework that runs on ASP.NET and HttpListener hosts and can be hosted on either .NET or Mono (trivia: www.servicestack.net is powered by CentOS/Mono). This allows your ServiceStack web services to be hosted on either:

  
  
  • IIS 5/6/7（使用的IHttpHandler）
  
  
  • VS.NET WebDevServer
  
  
  • 控制台应用程序或Windows图形用户界面
  
  
  • Windows服务
  
  
  • IIS 5/6/7 (uses IHttpHandler)
  • VS.NET WebDevServer
  • Console App or Windows GUI
  • Windows Service
  
  
  • 的Apache +是mod_mono
  
  
  • Nginx的+ MonoFastCGI
  
  
  • XSP
  
  
  • 控制台应用程序
  
  

  ServiceStack是它正在积极开放开发，一直下的自成立以来宽松的OSS许可证（新BSD）。截至今日，已收到捐款超过 47开发商以及它目前站立在GitHub上中的第三届最受瞩目的C＃项目。

  ServiceStack is a strong believer of the Open Source development model where it is actively developed in the open and has always been hosted under a liberal OSS licence (New BSD) since its inception. As of today it has received contributions from more than 47 developers and it currently stands at the 3rd most watched C# project on GitHub.

  我认为最大的缺点是它不是由微软开发的（甚至列为可用的选项），其他大多数OSS .NET项目相同。这意味着评估框架时，它很少能的首选。大多数的使用者仅评估ServiceStack作为最后的手段，在那里他们要么沮丧与施加的摩擦和WCF的脆性或$ P $的性能pferred微软堆栈。

  I believe the biggest disadvantage is the same for most other OSS .NET projects where it wasn't developed (or even listed as an available option) by Microsoft. This means it's rarely ever the first choice when evaluating a framework. Most adopters will only evaluate ServiceStack as a last resort, where they're either frustrated with the imposed friction and brittleness of WCF or the performance of the preferred Microsoft Stack.

  ServiceStack已与大多数人的正面评价谁已经评估它通过的在邮件组中的乐观情绪。截至今年 @ServiceStack 的Twitter帐户已被跟踪的提到，并在其收藏意见。

  ServiceStack has been very well received with positive feedback provided by most people who have evaluated it as visible by the positive sentiment in the mailing group. As of this year the @ServiceStack twitter account has been tracking mentions and feedback in its favorites.

  借助社区资源 wiki页面是了解更多的好去处ServiceStack与链接野外博客，波德演员，presentations，要旨等。

  The Community Resources wiki page is a good place to find out more about ServiceStack in the wild with links to Blog Posts, Pod Casts, Presentations, Gists and more.

  这篇关于ServiceStack VS ASP.Net的Web API的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！