ServiceStack vs ASP.Net Web API [cerrado]

299

Quiero escribir una nueva API de estilo REST y he analizado ServiceStack y me ha gustado bastante. Sin embargo, he visto que Microsoft lanzó el proyecto ASP.Net Web API como parte de la nueva versión beta de MVC 4. ¿Alguien ha mirado el nuevo proyecto de API web? ¿Puedes dar alguna ventaja / desventaja de cada sistema?

rotafolio
fuente

Respuestas:

389

Tienen casos de uso muy similares, como el responsable principal del proyecto ServiceStack, tengo una buena idea de las ventajas de ServiceStack y los muchos beneficios naturales de su diseño basado en mensajes. .

ServiceStack ha existido desde 2008 como un proyecto ejecutado por OSS desde su inicio con el único objetivo de promover el diseño e implementación correctos de servicios remotos sin fricción.

Diseño simple y elegante

En su búsqueda de la máxima simplicidad, se basa en un núcleo simple y elegante , con la mayoría de sus características vinculadas naturalmente a sus modelos , no a sus controladores, que es lo que hace MVC, WebApi (así como todos los demás marcos de servicios web que Microsoft ha producido )

La adopción de un diseño basado en mensajes ofrece un enfoque superior para los servicios remotos, ya que promueven servicios más extensibles y menos frágiles, simplifica el acceso y los patrones de llamadas, y contiene muchos otros beneficios naturales que obtienes de forma gratuita .

Como misión principal, luchamos contra la complejidad en cada etapa, con el objetivo de mantener una API invisible y no intrusiva y evitar la introducción de conceptos nuevos o construcciones artificiales que ya no son familiares para los desarrolladores de servicios web o .NET en la actualidad.

Como ejemplo, la IService<T>implementación de su servicio es solo una clase estándar de C # con dependencias cableadas automáticamente. Los envoltorios delgados y livianos se utilizan para proporcionar una API coherente y unificada en torno a los tipos principales de tiempo de ejecución IHttpRequest e IHttpResponse . También permiten el acceso a las clases subyacentes de ASP.NET o HttpListener Request and Response para que nunca esté restringido cuando usa ServiceStack.

En contraste con WCF y WebApi

Aquí hay una breve descripción de los estilos de API contrastantes que promueven ServiceStack y WCF . WebApi es diferente a WCF en que alienta el diseño de API REST-ful. En cuanto a los ejemplos entre los 2, este es el único ejemplo conocido que tengo con el mismo servicio escrito en ServiceStack y WebApi .

Servicios remotos de mejores prácticas

ServiceStack se centra principalmente en la simplicidad, el rendimiento y en la promoción de las mejores prácticas de servicio web / remoto centradas en adoptar los patrones de diseño de servicio remoto de Martin Fowlers en C # tan idiomático como sea posible:

  • El patrón de fachada : que sugiere el uso de interfaces discontinuas y de grano grueso cuando se comunica a través de los límites del proceso.

  • El patrón DTO ( MSDN ): dictar el uso de POCO de propósito especial para generar el formato de conexión de sus respuestas de servicios web.

  • los Patrón de puerta de enlace ( MSDN ) para encapsular las comunicaciones de su cliente y servidor entre los modelos de Puerta de enlace de cliente / DTO y los niveles de la Interfaz de servicio.

Estos patrones aseguran una separación limpia de las preocupaciones y una experiencia de desarrollo iterativa sin fricción.

Potenciando sus servicios

Un servicio web ServiceStack en su núcleo se centra en una IService<T>interfaz de C # pura, libre de dependencias y con cableado automático que le brinda total libertad para definir su contrato de servicio web con sus propios DTO de solicitud y respuesta utilizando POCO limpios, lo que hace que la API de ServiceStack sea prácticamente invisible y no -invasivo, es decir, es trivial extraer la lógica de los servicios de C # y ejecutarla fuera de un host ServiceStack.

Esta esencia es un buen ejemplo de lo que obtienes con solo 1 clase C # .cs en ServiceStack :

  • Páginas de metadatos para todos los formatos registrados
    • Con enlaces a WSDL, XSD y ejemplos de clientes C #
  • Vista de informe HTML amigable para humanos
    • Una única instantánea de página html autónoma (es decir, sin referencias externas). Incluye respuesta de servicio web JSON integrada: permite el acceso programático a las instantáneas de datos.
  • Mini Profiler incorporado (puerto del excelente MVC Mini Profiler )
    • Incluye perfiles SQL
  • Puntos finales JSON / JSONP, XML, JSV, CSV y SOAP

Las clases RestServiceBase y ServiceBase están destinadas a alojar su lógica C # personalizada para una reutilización potencial máxima como sea posible, por ejemplo, su diseño DTO-first permite trivialmente la ejecución diferida y aproximada donde su mismo servicio C # también se puede alojar y ejecutar en un host MQ que es lo que sucede cuando registra un hostIMessageService similar a RedisMQ y llama a su servicio a través del /asynconewaypunto final (es decirclient.SendOneWay() en Clientes C #)

También puede delegar y crear fácilmente servicios compuestos utilizando el base.ResolveService<T>()método que devuelve una instancia de conexión automática del servicio seleccionado, como se ve en el ejemplo del Servicio Nortwind CustomerDetails :

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

Devolver objetos simples de C #

En su mayor parte, ServiceStack serializará la mayoría de los objetos C # como se esperaba; aquí hay una lista de posibles tipos de retorno ( de esta respuesta ):

  • Cualquier objeto DTO -> serializado a Response ContentType
  • HttpResult, HttpError, CompressedResult (IHttpResult) para respuesta HTTP personalizada

Los siguientes tipos no se convierten y se escriben directamente en la secuencia de respuesta:

  • Cuerda
  • Corriente
  • IStreamWriter
  • byte []: con el tipo de contenido application / octet-stream.

Este ejemplo de CORS puede ver un ejemplo del soporte de encabezados HTTP personalizados donde puede configurar encabezados HTTP globalmente o por servicio.

Soporte HTML

Hay varias opciones para devolver HTML en ServiceStack que se explican en detalle aquí .

Incluye texto más rápido y serializadores binarios para .NET

Los serializadores resistentes y rápidos son de importancia primordial en una API para garantizar tiempos de respuesta rápidos y una API versionable que no rompa a los clientes existentes, por eso ServiceStack incluye los serializadores de texto más rápidos para .NET con una opción NuGet para habilitar el Protocolo de @marcgravell Buffers (serializador binario más rápido de .NET).

Los serializadores de texto de ServiceStack son muy resistentes y pueden soportar versiones extremas sin error.

Experiencia de desarrollo sin fricción de extremo a extremo

La naturaleza obstinada de ServiceStack permite una API de servicio web rápida, tipada y concisa de extremo a extremo con soporte integrado para clientes Sync / Async C # / .NET y Async Silverlight sin ningún código gen:

Ejemplo de sincronización de C #

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

Ejemplo asíncrono de C #

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

Como solo devuelve JSON puro, también se consume trivialmente con otros clientes HTTP, por ejemplo, ejemplo de cliente JS que usa jQuery :

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

Altamente comprobable

Todos los clientes de servicio C # / .NET comparten las mismas interfaces, lo que los hace altamente comprobables e intercambiables hasta el punto en que puede tener la misma prueba de unidad, también sirve como prueba de integración XML, JSON, JSV, SOAP .

Validación rica y manejo de errores incorporado

En su misión de proporcionar una experiencia de desarrollo limpia y sin fricciones, ServiceStack también incluye validación escrita y manejo de errores integrado, donde lanzar una excepción C # o usar su validación fluida integrada proporciona a los clientes errores estructurados y escritos fácilmente accesibles en clientes de servicios web , p.ej:

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)
    */
}

Para que resulte trivial consumir errores en JavaScript, puede usar la liviana biblioteca JavaScript ss-validation.js para vincular trivialmente sus errores de respuesta a sus campos de formulario HTML con una sola línea de código. El proyecto de ejemplo SocialBootstrapApi proporciona una buena demostración de esto.

Integración rica con ASP.NET y MVC

Los ServiceStack MVC PowerPack reescrituras y correcciones de muchos de los aflige de ASP.NET MVC y con los reemplazos para su paralizante Sesión y proveedores de ASP.NET XML gravados almacenamiento en caché con su propia aplicación limpia y libre de la dependencia de ICacheClient y las API ISession.

ServiceStack también incluye un modelo de proveedor de autenticación y autorización más nuevo y limpio con varios AuthProviders integrados:

  • Credenciales: para autenticarse con credenciales de nombre de usuario / contraseña publicando en el servicio / auth / credentials
  • Autenticación básica: permite a los usuarios autenticarse con autenticación básica
  • Twitter OAuth: permite a los usuarios registrarse y autenticarse en Twitter
  • Facebook OAuth: permite a los usuarios registrarse y autenticarse en Facebook

El módulo de autenticación es completamente opcional y está integrado en las API limpias ICacheClient / ISession y OrmLite, lo que permite que sus sesiones se almacenen en la memoria, Redis o Memcached y su información UserAuth persistió en los RDBMS admitidos por OrmLite de SQLServer, MySql, PostgreSQL, Sqlite como así como Redis data-store o InMemory (útil para desarrolladores / pruebas).

Gran documentación

ServiceStack está muy bien documentado donde la mayor parte de la información sobre el marco está alojada en el wiki de GitHub . La documentación para otras partes del marco (por ejemplo, serializadores, Redis, OrmLite) se puede encontrar en servicestack.net/docs/

El proyecto ServiceStack.Examples proporciona el código fuente de todas las demostraciones en vivo y plantillas de inicio de ServiceStack, mientras que el proyecto SocialBoostsrapApi proporciona un excelente punto de partida para desarrollar una aplicación de página única Backbone.js con ServiceStack y MVC basado en la plantilla Twitters Bootstrap.

Además de lo anterior, se encuentra un tesoro de información dentro del Grupo de Google que se ha expandido considerablemente en los últimos años.

Corre por todas partes

ServiceStack es un marco .NET 3.5 que se ejecuta en hosts ASP.NET y HttpListener y puede alojarse en .NET o Mono (trivia: www.servicestack.net funciona con CentOS / Mono). Esto permite que sus servicios web ServiceStack se alojen en:

Windows con .NET 3.5 y 4.0

Linux / OSX con Mono

  • Apache + mod_mono
  • Nginx + MonoFastCGI
  • XSP
  • Aplicación de consola

Desarrollado con el modelo de desarrollo Open Source

ServiceStack cree firmemente en el modelo de desarrollo de código abierto, donde se desarrolla activamente al aire libre y siempre se ha alojado bajo una licencia OSS liberal (New BSD) desde su inicio. Hasta el día de hoy, ha recibido contribuciones de más de 47 desarrolladores y actualmente se encuentra en el tercer proyecto C # más visto en GitHub .

Desventajas

Creo que la mayor desventaja es la misma para la mayoría de los otros proyectos OSS .NET donde Microsoft no lo desarrolló (o incluso lo enumeró como una opción disponible). Esto significa que rara vez es la primera opción al evaluar un marco. La mayoría de los adoptantes solo evaluarán ServiceStack como último recurso, donde están frustrados con la fricción impuesta y la fragilidad de WCF o el rendimiento del Microsoft Stack preferido.

Comentarios y recursos de la comunidad

ServiceStack ha sido muy bien recibido con comentarios positivos proporcionados por la mayoría de las personas que lo han evaluado como visible por el sentimiento positivo en el grupo de correo . A partir de este año, la cuenta de Twitter @ServiceStack ha estado siguiendo menciones y comentarios en sus favoritos .

La página wiki de Recursos de la comunidad es un buen lugar para obtener más información sobre ServiceStack en la naturaleza con enlaces a publicaciones de blog, podcasts, presentaciones, Gists y más.

mythz
fuente
30
Como alguien que ha intentado usar WCF, webapi y ahora ServiceStack, quédese con ServiceStack. 1) WCF es innecesariamente demasiado complejo para la mayoría. Es el viejo "resolvamos todos los problemas" delima. 2) web-api es demasiado nuevo. Espera el lanzamiento final. Ni siquiera admite publicaciones de formas de parte muli. El código está en un estado de cambio. No ejecutaría aplicaciones comerciales en él. Por cierto, esta pregunta no debe cerrarse.
Michael Silver
13
¿Podría editar esto para ASP.NET WebAPI que se acaba de lanzar?
Blake Niemyjski el
26
Haga que su sitio web sea más fácil de usar. Esto parece una gran herramienta. Pero el sitio es confuso. No está claro qué es el proyecto y qué pretende resolver. En contraste, esta respuesta es fantástica.
Kugel
82
Esto realmente no parece ser una gran comparación con la API web. Tiene sentido: en el momento de la respuesta, la API web era completamente nueva. Este ya no es el caso. Realmente me encantaría ver un colapso real y me temo que esta respuesta está desactualizada.
George Mauer
35
Puede valer la pena señalar que ServiceStack se está moviendo a una distribución solo comercial / binaria a partir de v4.0. Vea la publicación de Demis en Google+ para más detalles.
Nick Jones
137

Hay una nueva diferencia principal que debe tenerse en cuenta: ServiceStack ya no es de uso gratuito a partir de v4. Dado que hay una respuesta bastante definitiva en los SS pro, quería lanzar un par para API web

API web

Pro:

  1. De uso gratuito en su proyecto (siempre que tenga una licencia VS que permita el uso comercial)
  2. Extraordinariamente alto nivel de soporte gratuito disponible de Microsoft y en toda la web, incluido aquí en StackOverflow.com.
  3. Se integra rápidamente con otras pilas de tecnología de Microsoft como ASP.NET MVC, que es extremadamente popular en las tiendas de Microsoft
  4. Soporte integrado para autenticación y autorización RESTful en su pila de Microsoft

Contras :

  1. No es compatible con SOAP

Beneficios auxiliares

(Por favor, siéntase libre de dejar comentarios a continuación, agregando por qué la API web tiene beneficios o tiene pros / contras que puedo agregar)

PW Kad
fuente
84
No estoy seguro de que no sea compatible con SOAP es una estafa
D.Rosado
11
El hecho de que MVC y WebAPI coexistan es una CON.
Phill
44
ServiceStack v3 todavía es de uso gratuito y AFAIK siempre lo será, no creo que nada de los mitos mencionados sea específico de v4.
Kyle Gobel
14
Wow, "ya no es gratis" es un eufemismo. ¿$ 999 por desarrollador para una empresa con más de diez empleados?
Ryan Lundy
77
Mi razón principal para cambiar de Service Stack a Web API es que Service Stack v3 ya no es compatible con iOS (que usa Xamarin) con el nuevo requisito de arquitectura de 64 bits. Por supuesto, las actualizaciones están en v4, que es la versión paga.
SgtRock
21

Realmente no puedo decir mucho sobre ServiceStack, pero la API web tiene muchas características excelentes y actualmente está en la versión 2.

Algunas de las cosas que puede hacer con la API web:

  • Auto host en una aplicación OWIN (es decir, se ejecuta en cualquier lugar).
  • Soporte completo para asyncy await.
  • Buenas plantillas predeterminadas y toneladas de ejemplos de código abierto.
  • Utiliza gran serializador Json.Net JSON.
  • Rest-ish por defecto (tendrás que hacer hipermedia tú mismo).
  • y más...
usuario3377837
fuente
1
Todo en esta lista también está presente en ServiceStack o puede verse como una estafa. El serializador JSON de ServiceStack, aunque es menos popular, es mucho más rápido que JSON.NET. Es poco probable que se implemente el soporte de OWIN porque @mythz tiene fuertes opiniones en contra de esta tecnología, que son bastante sólidas ( vea sus comentarios sobre esta solicitud de características ).
ygormutti
3
Mirando el paquete nuget de OWIN que no se ha actualizado desde que se publicó hace tres años, realmente no veo el punto en todo este bombo en torno al soporte de OWIN. Parece que la gente realmente quiere tener OWIN porque Microsoft dijo una vez que es genial. De lo contrario, probablemente nunca escuches nada sobre OWIN. Microsoft felizmente lo dejó a favor de su nuevo juguete K. Esto mitiga el argumento "Microsoft está detrás de esto para que viva para siempre" ya que Microsoft tiene una fuerte tendencia a matar proyectos que fueron fuertemente impulsados ​​por ellos.
Alexey Zimarev
¿Por qué responder si no tiene experiencia con ServiceStack?
Brian Ogden
3

Hace un año que uso SS y todo es genial. ORMLite es pura magia. Pude reasignar una base de datos MySQL horrible para integrarla en aplicaciones móviles. No hay cambios en la base de datos porque se usa con un backend php con otras aplicaciones ...

Mythz es un ejemplo de soporte y explicación. Se mejoró mi conocimiento sobre el diseño de aplicaciones y la simplicidad en el mantenimiento. Por favor, inténtalo y lo entenderás.

Además, no compare SS con WebAPI. No es suficiente, las SS aportan mucho más a su caja de herramientas. ServiceStack.Text también es un gran Automapper.

André Leblanc
fuente