Je veux écrire une nouvelle API de style REST et j'ai regardé ServiceStack et tout à fait comme ça. Cependant, j'ai vu que Microsoft a publié le projet d'API Web ASP.Net dans le cadre de la nouvelle version bêta de MVC 4. Quelqu'un a-t-il examiné le nouveau projet d'API Web? Pouvez-vous donner des avantages / inconvénients de chaque système?
Réponses:
Ils ont des cas d'utilisation très similaires, en tant que responsable principal du projet ServiceStack, j'ai un bon aperçu des avantages de ServiceStack et des nombreux avantages naturels de sa conception basée sur les messages .
ServiceStack existe depuis 2008 en tant que projet géré par OSS depuis sa création avec un seul objectif de promouvoir la conception et la mise en œuvre correctes de services à distance sans friction.
Dans sa quête de simplicité ultime, il est construit autour d' un noyau simple et élégant - avec la plupart de ses fonctionnalités se liant naturellement à vos modèles , pas à vos contrôleurs - ce que fait MVC, WebApi (ainsi que tous les autres frameworks de services Web que Microsoft a produits ).
L'adoption d'une conception basée sur les messages offre une approche supérieure pour les services distants, dans la mesure où ils favorisent des services plus extensibles et moins fragiles, simplifient les modèles d'accès et d'appel et contiennent de nombreux autres avantages naturels que vous obtenez gratuitement .
En tant que mission principale, nous combattons la complexité à chaque étape, dans le but de garder une API invisible et non intrusive et d'éviter d'introduire de nouveaux concepts ou constructions artificielles qui ne sont pas déjà familiers aux développeurs .NET ou de services Web aujourd'hui.
Par exemple, votre IService<T>implémentation de service n'est qu'une classe C # standard avec des dépendances câblées automatiquement. Des wrappers fins et légers sont utilisés pour fournir une API cohérente et unifiée autour des principaux types d' exécution IHttpRequest et IHttpResponse . Ils permettent également d'accéder aux classes sous-jacentes ASP.NET ou HttpListener Request and Response afin que vous ne soyez jamais restreint lorsque vous utilisez ServiceStack.
Voici un bref aperçu des styles d'API contrastés que ServiceStack et WCF promeuvent . WebApi est différent de WCF en ce qu'il encourage la conception d'API REST-ful. En ce qui concerne les exemples entre les 2, c'est le seul exemple connu que j'ai avec le même service écrit à la fois dans ServiceStack et WebApi .
ServiceStack se concentre principalement sur la simplicité, les performances et la promotion des meilleures pratiques de services Web / distants centrées sur l'adoption des modèles de conception de services à distance Martin Fowlers en C # aussi idiomatique que possible:
Le modèle de façade - qui suggère l'utilisation d'interfaces groupées et à granularité grossière lorsque vous communiquez au-delà des limites du processus.
Le modèle DTO ( MSDN ) - Dicter l'utilisation de POCO à usage spécial pour générer le format de fil de vos réponses de services Web.
Le modèle de passerelle ( MSDN ) pour encapsuler vos communications client et serveur entre les modèles Client Gateway / DTO et les niveaux Interface de service.
Ces modèles garantissent une séparation nette des préoccupations et une expérience de développement itérative sans friction.
Un service Web ServiceStack est centré autour d'une IService<T>interface pure C # sans dépendance et câblée automatiquement qui vous donne une liberté totale pour définir votre contrat de service Web avec vos propres DTO de demande et de réponse à l'aide de POCO propres - rendant l'API de ServiceStack pratiquement invisible et non -invasive, c'est-à-dire qu'il est trivial d'extraire votre logique de services C # et de l'exécuter en dehors d'un hôte ServiceStack.
Cet élément est un bon exemple de ce que vous obtenez avec seulement 1 classe C # .cs dans ServiceStack :
Les classes RestServiceBase et ServiceBase sont destinées à héberger votre logique C # personnalisée pour une réutilisation potentielle maximale, par exemple. qui est ce qui se passe lorsque vous enregistrez un IMessageServicecomme l' hôte RedisMQ et appelez votre service via le /asynconewaypoint final ( par exemple client.SendOneWay()en C # clients)
Vous pouvez également facilement déléguer et créer des services composites à l'aide de la base.ResolveService<T>()méthode qui renvoie une instance câblée automatiquement du service sélectionné, comme illustré dans l' exemple du service Nortwind CustomerDetails :
var ordersService = base.ResolveService<OrdersService>();
var ordersResponse = (OrdersResponse)ordersService.Get(
new Orders { CustomerId = customer.Id });
Pour la plupart, ServiceStack sérialisera la plupart des objets C # comme prévu - voici une liste des types de retour possibles (à partir de cette réponse ):
Les types suivants ne sont pas convertis et sont écrits directement dans Response Stream:
Un exemple de prise en charge des en-têtes HTTP personnalisés peut être vu par cet exemple CORS où vous pouvez configurer les en-têtes HTTP globalement ou par service.
Il existe plusieurs options pour retourner du code HTML dans ServiceStack, qui sont expliquées en détail ici .
Les sérialiseurs résilients et rapides sont d'une importance primordiale dans une API pour garantir des temps de réponse rapides et une API versionnable qui ne casse pas les clients existants, c'est pourquoi ServiceStack inclut les sérialiseurs de texte les plus rapides pour .NET avec une option NuGet pour activer le protocole de @marcgravell Buffers (le sérialiseur binaire le plus rapide de .NET).
Les sérialiseurs de texte de ServiceStack sont très résistants et peuvent résister à des versions extrêmes sans erreur.
La nature avisée de ServiceStack permet une API de service Web rapide, typée et laconique de bout en bout avec prise en charge intégrée des clients Sync / Async C # /. NET et Async Silverlight sans aucune génération de code:
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; });
Comme il retourne simplement du JSON pur, il est également trivialement consommé avec d'autres clients HTTP, par exemple l'exemple de client JS utilisant jQuery :
$.getJSON("http://localhost/Backbone.Todo/todos", function(todos) {
alert(todos.length == 1);
});
Tous les clients C # / .NET Service partagent les mêmes interfaces, ce qui les rend hautement testables et échangeables au point où vous pouvez faire en sorte que le même test unitaire serve également de test d' intégration XML, JSON, JSV, SOAP .
Dans sa mission de fournir une expérience de développement propre et sans friciton, ServiceStack comprend également une validation typée et une gestion des erreurs intégrée où le lancement d'une exception C # ou l'utilisation de sa validation Fluent intégrée fournit aux clients des erreurs typées structurées facilement accessibles sur les clients de services Web , par exemple:
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)
*/
}
Pour simplifier la consommation d'erreurs en JavaScript, vous pouvez utiliser la bibliothèque JavaScript légère ss-validation.js pour lier trivialement vos erreurs de réponse à vos champs de formulaire HTML avec une seule ligne de code. L' exemple de projet SocialBootstrapApi en fournit une bonne démonstration.
Les ServiceStack MVC PowerPack réécritures et corrige beaucoup des maux de ASP.NET MVC et avec le remplacement de sa paralysante session et les fournisseurs ASP.NET grevés XML-caching avec sa propre implémentation propre et sans dépendance de ICacheClient et les API ISession.
ServiceStack comprend également un modèle de fournisseur d'authentification et d'autorisation plus récent et plus propre avec un certain nombre d'AuthProviders différents intégrés:
Le module d'authentification est entièrement facultatif et est basé sur les API ICacheClient / ISession propres et OrmLite qui permet à vos sessions d'être stockées dans la mémoire, Redis ou Memcached et vos informations UserAuth persistaient dans les SGBDR pris en charge par OrmLite de SQLServer, MySql, PostgreSQL, Sqlite as ainsi que le magasin de données Redis ou InMemory (utile pour le développement / test).
ServiceStack est très bien documenté où la plupart des informations sur le framework sont hébergées sur le wiki GitHub . La documentation pour d'autres parties du framework (par exemple Serializers, Redis, OrmLite) peut être trouvée sur servicestack.net/docs/
Le projet ServiceStack.Examples fournit le code source de toutes les démos en direct et modèles de démarrage de ServiceStack tandis que le projet SocialBoostsrapApi fournit un excellent point de départ pour développer une application de page unique Backbone.js avec ServiceStack et MVC basée sur le modèle d'amorçage Twitters.
En plus de ce qui précède, un trésor d'informations est contenu dans le groupe Google, qui s'est considérablement développé ces dernières années.
ServiceStack est un framework .NET 3.5 qui s'exécute sur des hôtes ASP.NET et HttpListener et peut être hébergé sur .NET ou Mono (trivia: www.servicestack.net est alimenté par CentOS / Mono). Cela permet à vos services Web ServiceStack d'être hébergés sur:
ServiceStack est un fervent partisan du modèle de développement Open Source, où il est activement développé en plein air et a toujours été hébergé sous une licence OSS libérale (New BSD) depuis sa création. À ce jour, il a reçu des contributions de plus de 47 développeurs et se situe actuellement au 3ème projet C # le plus regardé sur GitHub .
Je pense que le plus gros inconvénient est le même pour la plupart des autres projets OSS .NET où il n'a pas été développé (ou même répertorié comme option disponible) par Microsoft. Cela signifie que c'est rarement le premier choix lors de l'évaluation d'un cadre. La plupart des adoptants n'évalueront ServiceStack qu'en dernier recours, lorsqu'ils sont frustrés par le frottement et la fragilité imposés de WCF ou par les performances de la pile Microsoft préférée.
ServiceStack a été très bien reçu avec des commentaires positifs fournis par la plupart des gens qui l'ont évalué comme visible par le sentiment positif dans le groupe de diffusion . Depuis cette année, le compte Twitter @ServiceStack suit les mentions et les commentaires dans ses favoris .
La page wiki des ressources de la communauté est un bon endroit pour en savoir plus sur ServiceStack dans la nature avec des liens vers des articles de blog, des podcasts, des présentations, des Gists et plus encore.
Il y a une nouvelle différence principale qui doit être prise en compte - ServiceStack n'est plus gratuit à utiliser à partir de la v4. Puisqu'il y a une réponse assez définitive sur les SS pro, je voulais en jeter quelques-uns pour l'API Web
Avantages :
Les inconvénients :
Avantages accessoires
(N'hésitez pas à laisser des commentaires ci-dessous pour expliquer pourquoi l'API Web présente des avantages ou présente des avantages / inconvénients que je peux ajouter)
Je ne peux pas vraiment en dire beaucoup sur ServiceStack, mais l'API Web possède de nombreuses fonctionnalités intéressantes et est actuellement à la version 2.
Certaines des choses que vous pouvez faire avec l'API Web:
asyncet await.En tant que client de ServiceStack, voici le pro de ServiceStack le plus important pour moi.
https://github.com/ServiceStack/Issues/issues/606
Alors. Bug trouvé, bug identifié, bug corrigé. Même jour. Un soutien extraordinaire!
Ça fait un an que j'utilise SS et c'est super. ORMLite est une pure magie. J'ai pu remapper une base de données MySQL impressionnante pour l'intégrer dans une application mobile. Aucun changement sur la base de données car elle est utilisée avec un backend php avec d'autres applications ...
Mythz est un exemple de support et d'explication. Cela a amélioré mes connaissances en matière de conception d'applications et de simplicité de maintenance. Veuillez l'essayer et vous comprendrez.
Aussi, ne comparez pas SS avec WebAPI. Ce n'est pas suffisant, SS apporte beaucoup plus à votre boîte à outils. ServiceStack.Text est également un excellent Automapper.