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?
Respuestas:
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.
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.
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 .
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.
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 :
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 });
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 ):
Los siguientes tipos no se convierten y se escriben directamente en la secuencia de respuesta:
Este ejemplo de CORS puede ver un ejemplo del soporte de encabezados HTTP personalizados donde puede configurar encabezados HTTP globalmente o por servicio.
Hay varias opciones para devolver HTML en ServiceStack que se explican en detalle aquí .
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.
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:
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; });
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);
});
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 .
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.
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:
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).
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.
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:
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 .
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.
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.
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
Pro:
Contras :
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)
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:
asyncy await.Como cliente de ServiceStack aquí es el profesional de ServiceStack más importante para mí.
https://github.com/ServiceStack/Issues/issues/606
Entonces. Error encontrado, error identificado, error corregido. Mismo día. Apoyo extraordinario!
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.