web-dev-qa-db-fra.com

Quel cadre utiliser pour les services RESTful dans .net

Je sais que des questions similaires ont été posées, mais la plupart d'entre elles sont dépassées. Donc, nous y revoilà :). J'ai besoin d'implémenter une couche de service REST) complète pour notre application. Le problème que j'ai est de savoir quel framework serait le meilleur pour résoudre ce problème. J'ai juste besoin d'un framework Nice qui me permette de me concentrer sur le problème et pas sur le REST ou ce qui est requis. L'authentification est une fonctionnalité requise. Voici quelques-unes de mes idées, qu'en pensez-vous?

  • WCF: À mon avis, c'est un cadre surchargé qui rend les choses compliquées.
  • ServiceStack: Semble être une alternative agréable, légère et open source. Mais que faire s'ils décidaient d'arrêter le développement?
  • Implémentation personnalisée utilisant asp.net mvc comme this , mais pourquoi réinventer la roue?
c#asp.netweb-servicesrestservice
22
raisr

J'ai commencé à l'origine ServiceStack en raison de l'inefficacité (développement et exécution) et des frictions imposées lors de la création de services Web avec des frameworks .NET alternatifs.

Sérialisation Json 3-4x plus rapide que MVC

ServiceStack a une forte performance de mise au point comme nous le croyons il fournit le meilleur UX pour l'utilisateur final c'est pourquoi il est intégré avec un ensemble solide de fournisseurs de mise en cache comprenant le - Sérialiseur JSON le plus rapide pour .NET - à 4 fois plus rapide que les sérialiseurs livrés avec .NET et MVC (son JavaScriptSerializer par défaut est le plus lent dans .NET). Pour des performances optimales, aucune réflexion d'exécution ou expression régulière n'est utilisée. Il utilise une correspondance de route non linéaire intelligente et il est recommandé d'utiliser les fournisseurs de mise en cache intégrés beaucoup plus rapides pour contourner le performances médiocres de la session ASP.NET .

Axé sur le développement typé, itératif et basé sur le code

ServiceStack vous permet de développer des services Web fortement typés promouvant les meilleures pratiques en utilisant le minimum de code et automatiquement sans aucun code-gen, config, pré/post build-étapes, etc.

Exemple d'un simple service Hello World :

public class Hello { public string Name { get; set; } }
public class HelloResponse { public string Result { get; set; } }

public class HelloService : IService 
{
    public object Get(Hello request) 
    {
        return new HelloResponse { Result = "Hello, " + request.Name };
    }
}

Avec juste ces classes, tous vos services Web sont automatiquement mis à disposition dans une variété de formats différents (JSON, XML, JSV, CSV, SOAP) tous prêts à l'emploi sans effort .

Exemple d'API client fortement typé utilisant C #:

var client = new JsonServiceClient("http://localhost/Service");
var response = client.Send<HelloResponse>(new Hello { Name = "World!" });

Exemple JavaScript utilisant jQuery:

$.getJSON("http://localhost/Service/hello/World!", function(r) {
    console.log(r.Result);
});

Développement convivial

Étant donné que la visualisation des services Web est importante lors du développement itératif de services Web, le type de contenu par défaut lors de l'affichage des services Web dans un navigateur est un format convivial Rapport JSON HTML5 (également disponible de manière autonome à http://ajaxstack.com/jsonreport/ ) qui vous permet de visualiser la réponse de vos services web en un coup d'œil.

Vous obtenez également une page de métadonnées générée automatiquement (que vous pouvez annoter avec votre propre description personnalisée) qui constitue un excellent moyen de documenter votre API de service Web.

Mais que faire s'ils décidaient d'arrêter le développement

En tant que créateur de ServiceStack, je ne me vois pas abandonner le développement dans un avenir prévisible. Je construis des systèmes avec lui tous les jours simplement parce que je trouve que c'est un cadre plus propre, plus rapide et plus productif pour développer.

Promeut les meilleures pratiques

Il existe très peu de frameworks de services Web .NET qui promeuvent une architecture basée sur le premier message DTO permettant le modèle d'interface de service - Une meilleure pratique de services Web couramment observée dans le = Java facilitant le développement de services Web basés sur SOA à gros grains par lots.

Il y a 0 risque il sera abandonné au profit d'un autre framework de service Web .NET. Tout simplement parce que nous ne croyons pas qu'aucun autre framework .NET promeut activement les meilleures pratiques des services Web (c'est-à-dire les modèles DTO/Façade distante et Interface de service) et un accent principal sur les performances.

Mais même en tant que projet Open Source avec près de 20 contributeurs, cette crainte est mitigée. Combien de frameworks propriétaires et fermés MS a-t-il abandonné et obligé tout le monde à passer à un successeur? Les logiciels open source évoluent, ils ne sont pas abandonnés et réécrits.

Tout le code source de ServiceStack vit sous http://github.com/ServiceStack il n'y a pas de verrouillage et GitHub permet à quiconque de facilement bifurquer et de poursuivre le développement comme beaucoup l'ont déjà fait.

Fonctionne partout

Enfin, ServiceStack peut s'exécuter sur n'importe quel hôte ASP.NET dans IIS 6/7 sous Windows ou Linux/OSX en utilisant Mono. Il prend également en charge un hôte HttpListener autonome vous permettant de l'exécuter sans serveur Web, c'est-à-dire intégré dans n'importe quelle console ou application Windows, à l'intérieur d'un service Windows et a même hébergé dans une application iPhone MonoTouch .

22
mythz

J'ai joué avec Nancy moi-même ces derniers temps et je considère également Manos de Mono . Voici un exemple de la page d'accueil sur Nancy.

public class HelloModule : NancyModule
{
    public HelloModule()
    {
        Get["/"] = parameters => "Hello World";
    }
}
22
kenny

Pour moi, la solution la plus simple et la plus propre serait d'implémenter les services en tant que contrôleurs dans ASP.NET MVC3 avec des méthodes qui renvoient un JsonResult.

Avantages:

  • Le framework MVC fait le gros du travail pour vous

  • Vous pouvez implémenter la validation du modèle à l'aide d'attributs au lieu de code

  • Déploiement de XCopy vers n'importe quelle version d'IIS

7
DaveRead

Si je commençais cela aujourd'hui, je choisirais parmi votre troisième option de faire quelque chose de personnalisé dans ASP.NET MVC3 ou d'utiliser l'un des cadres ci-dessous.

3
Mark Perry

La solution Shoulders Of Giants est désormais disponible via CodePlex et NuGet ... renommé en tant que Resources Over MVC.

1
Piers Lawson