2010-11-15 23 views
1

J'utilise OpenRasta 2.0 pour construire une API REST et son extensibilité est fantastique - nous avons réussi par exemple à utiliser l'authentification OAuth plug-in en utilisant DotNetOpenAuth assez facilement.Lors de la gestion des exceptions dans les gestionnaires OpenRasta, quelle est la meilleure façon de convertir une réponse?

Cependant, je suis arrivé au point où je dois définir nos réponses aux conditions d'erreur. Nous l'adoption des normes en ce qui concerne les codes d'erreur HTTP - mais je suis concious de retour des réponses significatives et, un peu comme Twitter (l'exemple éternel de REST) ​​fait:

{ 
"error":"This method requires authentication.", 
"request":"\/1\/statuses\/followers.json" 
} 

est la meilleure façon de retourner un OperationResult de tous nos gestionnaires, capturez manuellement les exceptions et mappez-les à ResponseResource? Cela me semble être une bonne quantité de frais généraux par rapport à la façon dont fonctionne le reste de OpenRasta. Ou devrions-nous écrire une sorte de contributeur pour capturer les exceptions jetées dans le pipeline et gérer globalement les problèmes? Peut-être traduire seulement des exceptions de types particuliers (RestException?). Fondamentalement, je suis après un sentiment pour ce que la meilleure pratique pour ce serait et comment les autres l'ont manipulé.

Merci.

EDIT:

Après avoir regardé depuis un certain temps aujourd'hui, je vais avoir du mal à comprendre comment envelopper l'appel de gestionnaire - je me suis déclaré une classe dérivée de OperationInterceptor et ont accroché que dans le pipeline avec et définissez une dépendance personnalisée ResourceSpace.Uses.CustomDependency<IOperationInterceptor, ExceptionHandlerInterceptor>(DependencyLifetime.PerRequest), mais peu importe dans lequel des méthodes que j'essaie et envelopper dans un try-catch, l'exception bulles encore. C'est RewriteOperation, BeforeExecute ou AfterExecute est l'endroit le plus approprié pour piéger - et si oui pouvez-vous me donner une idée sur la façon de commencer?

Merci.

+1

N'ajoutez pas le OperationInterceptorContributor, ce n'est pas nécessaire. Vous pouvez ajouter votre intercepteur d'opération en tant qu'attribut sur la méthode ou le gestionnaire sur lequel vous voulez que la fonction fonctionne, ou simplement enregistrer l'intercepteur dans votre conteneur IoC pour l'interface IOperationInterceptor (et le rendre transitoire), et vous avez terminé, que vous pouvez soit faire dans votre IoC de choix ou par la méthode .Has.CustomDependency. – SerialSeb

+1

Il semble que j'ai manqué celui-là. C'est dans la réécriture, vous encapsulez l'appel d'origine (le délégué est passé à la méthode de réécriture) dans votre try/catch. – SerialSeb

Répondre

5

Il y a deux ou trois choses que vous pouvez faire pour réaliser ce que vous voulez. D'abord, vous pouvez construire un IOperationInterceptor qui encapsule l'appel de votre gestionnaire dans un bloc try/catch, et affecter le bon OperationResult au ICommunicationContext.

Ensuite, si vous voulez que ceci soit sérialisé dans json, vous voudrez assigner la propriété ResponseResource de votre résultat d'opération à un type qui décrit votre erreur (appelons-le "TitsUpResource" pour l'instant).

Enfin, le registre de ce type comme une ressource sans URI, de sorte que vous pouvez ajouter le codec JSON il

ResourceSpace.Has.ResourcesOfType(). WithoutUri.TranscodedBy ou tout ce que vous voudrez peut-être.

+0

Lol réponse exceptionnelle, merci Seb - qui mieux vaut l'obtenir que l'homme lui-même. +1 en particulier pour TitsUpResource! –

+0

Cela vous dérangerait-il de regarder ma nouvelle question dans mon édition? Je ne peux pas le faire fonctionner encore. Merci. –

+0

Comment appliquer le 'StatusCode' de la réponse HTTP lors de la définition de' OperationResult' dans un 'IOperationInterceptor'? Pour moi, il revient juste à 200. –