API succincte et légère: REST + JSON dans .NET

Résumé: J’ai besoin de savoir s’il existe une implémentation allégée de REST + JSON dans le monde .NET qui n’utilise pas WCF. Sinon, je recherche des personnes qui seraient intéressées à démarrer une joint-venture pour un projet Open Source.

Je ne sais pas pour vous, mais j’étais un grand fan de la WCF lorsqu’elle est sortie et j’ai loué son design pour sa modularité et son extensibilité. Cependant, à mesure que je l’utilisais de plus en plus souvent, des problèmes fondamentaux ont commencé à apparaître, à un point tel que je sens maintenant qu’il faut le supprimer et le redéfinir. Cela semble être une déclaration importante, mais je crois que ce sont des problèmes majeurs:

Tout d’abord, WCF utilise en interne SOAP pour message, ce qui signifie que si le message de transport n’est pas SOAP, nous assumons le coût de la transformation vers et depuis SOAP pour chaque appel. C’est cher et prend du temps.
Transformer le message sortant nécessite de “twigr” un inspecteur de message et de “voler” le message. Comme son nom l’indique, il s’agit d’un inspecteur (qui doit être utilisé pour l’inspection et la journalisation). Son utilisation pour modifier le message est franchement un hack.
Il a été conçu selon WSDL et le monde a beaucoup changé depuis 2001. La mise en œuvre de REST nécessite également de voler le message. WCF a été conçu selon WSDL et non pas REST.
La stack de canaux est inutilement lourde.
La stack principale est agnostique selon les protocoles. Ce n’est pas un avantage, c’est un défaut fondamental. Comme vous le savez, l’access à de nombreuses informations au niveau du protocole a été ajouté ultérieurement, car il était impossible d’implémenter certains scénarios utilisateur importants. Par exemple, l’adresse IP du client dans TCP n’était pas accessible et ajoutée ultérieurement (maintenant accessible à l’aide de perationContext.Current.IncomingMessageProperties [RemoteEndpointMessageProperty.Name])
L’interopérabilité avec d’autres plateformes peut être un problème.

Il semble maintenant que beaucoup de conceptions se dirigent vers la simplicité de JSON et de REST. J’adore leur simplicité et je vois que ma machine à laver consum du JSON dans 5 à 10 ans et héberge un service REST! Je pense que leur implémentation dans .NET est un hack et que nous avons sérieusement besoin d’un framework simple et très léger (car ils sont simples et légers) pour héberger les services REST + JSON à l’intérieur et à l’extérieur d’IIS. J’espère qu’un tel cadre existe, mais si ce n’est pas le cas, je suis vraiment désireux de faire quelque chose avec un certain nombre de personnes partageant les mêmes idées.

Alors qu’est-ce que tu en penses? Un tel cadre existe-t-il? Si non, est-ce que quelqu’un est intéressé?

MVC qui crache JSON au lieu de HTML semble être une possibilité. Vous avez la liberté d’utiliser JsonDataContractSerializer ou JSON.Net pour sérialiser vos contrats de données.

Jetez un coup d’oeil à OpenRasta . On dirait que cela répond à beaucoup de vos préoccupations.

Si vous ne voulez vraiment pas utiliser IIS, vous pouvez implémenter votre propre processus d’écoute HTTP. Cela vous permet d’écrire votre propre application autonome pour répondre aux demandes HTTP (qui peut être exécutée en tant que service si vous le souhaitez) sans l’impact négatif d’IIS, de WCF ou de tout autre framework de processus de conteneur. Votre processus vivrait au-dessus de la fonctionnalité HTTP.sys exposée par Windows et exposée par le framework .Net via la classe HttpListener.

Consultez le site http://msdn.microsoft.com/en-us/library/system.net.httplistener.aspx

Notez que vous devrez écrire votre propre infrastructure pour faire correspondre les demandes entrantes et les envoyer aux gestionnaires correspondants (l’équivalent de UrlRoutingModule / RouteTable.Routes d’ASP.Net MVC), et vous devrez faire passer le HttpListenerContext partout pour pouvoir l’examiner. la demande entrante et la compléter. Mais cela vous donne la flexibilité ultime dans ce que vous pouvez faire.

Et cela fonctionne certainement – j’ai testé une implémentation de base de HttpListener sur une machine de bureau standard à plus de 3 000 demandes servies / seconde, de sorte que la structure elle-même ne vous retienne pas.

Il y a MicroRest , un projet open source que j’ai démarré il y a longtemps . Voici le texte de présentation que j’ai écrit:

MicroRest est un petit framework REST – 5 classes, environ 500 lignes de code. Toutes les sorties sont en JSON. Il vous permet d’append des fonctionnalités REST à vos applications ASP.NET sans avoir à passer par l’énorme désordre du rest de la WCF (qui ne fournit pas d’URL «propres» dans la version 3.5). Il vous permet également d’utiliser des POCO (et des objects complexes dans certains cas) dans vos méthodes REST, où WCF vous limite à l’utilisation d’ints et de chaînes.

Les consortingbutions sont les bienvenues – elles reposent sur System.Web.Routing, il faut donc Cassini / IISExpress en tant que serveur Web intégré. Je cherche à écrire un parsingur d’itinéraire personnalisé afin qu’il puisse être déplacé vers Kayak.