2009-05-20 7 views
2

Je suis en train de jouer avec l'assemblage SimplyRestfulRouting fourni avec les extras de MvcContrib, et j'aime beaucoup le fait qu'il configure rapidement mes itinéraires et me laisse une bonne convention à suivre dans mes contrôleurs. Cependant, j'essaie toujours de comprendre REST en ce qui concerne les applications Internet riches et je me sens parfois coincé quand j'ai besoin de faire quelque chose qui sort du cadre de ces 8 ou 9 routes par défaut. [Edit: Par "pigeon holed", je veux simplement dire que j'ai l'impression de salir l'application quand je dois créer une action de contrôleur qui est en dehors de la définition des routes reposful par défaut.]Quels sont les avantages de l'application de routes reposantes dans une application MVC?

J'ai entendu un commentaire d'un promoteur REST dans lequel il a exprimé son opinion que le framework MVC est intrinsèquement RESTful, et cela m'a fait réfléchir un peu plus sur ce que les bibliothèques comme le SimplyRestfulRouting de MvcContrib m'achètent. N'ayant pas beaucoup lu sur les principes concrets de REST, je cherche des informations sur les avantages qui pourraient découler de l'application d'une telle chose dans le contexte d'une RIA de formulaires sur données. Et en ce qui concerne AJAX, comment une architecture RESTful affecte-t-elle mon interaction avec le client?

Il est probable que je me méprends sur l'utilisation de REST dans ce contexte, et j'apprécierais un peu de mojo StackOverflow pour obtenir ma tête droite.

+0

-vous avoir un lien à propos de ce promoteur REST et pourquoi MVC est "intrinsèquement" reposant? – SerialSeb

+0

Il était une discussion sur .NET Rocks, spectacle # 445 avec Kenn Scribner: http://www.dotnetrocks.com/default.aspx?showNum=445 – nkirkes

Répondre

2

Le principal avantage que je peux voir dans l'application des routes RESTful - quel que soit le cadre utilisé - est la cohérence. Vous serez toujours capable de savoir comment l'API fonctionnera pour n'importe quelle ressource, ce qui vous donnera en fait une API auto-documentée.

Il fournit également une contrainte merveilleuse tout en architecturant l'application. Plutôt que d'avoir une API avec une ardoise vierge qui pourrait se compliquer très rapidement, contraindre les routes vers les bases vous guidera quant aux ressources que vous aurez besoin de créer.

Pour plus de principes de base entourant REST, je vous recommande de lire ceci thread.

+0

Je ne voulais pas laisser la question ouverte, et toutes les réponses étaient utile. Ce poste particulier comprenait un fil que j'ai trouvé utile pour approfondir ma compréhension de REST. – nkirkes

1

Etre RESTful, c'est plus que simplement avoir des URL propres.

Au niveau architectural, le repos est d'organiser votre fonctionnalité d'application en termes de ressources et l'exposition d'un fixe et uniforme ensemble des opérations CRUD sur eux (par exemple HTTP POST/GET/PUT/DELETE méthodes). Ceci est connu comme Resource Oriented Architecture.

En revanche, avec Service Oriented Architecture vous organiser généralement une fonctionnalité d'application en termes de processus ou composants, et non exposes application uniforme, des méthodes spécifiques sur eux (par exemple via SOAP). Remarquez que vous pouvez avoir des URL propres tout en respectant les principes de conception SOA non-RESTful.

MISE À JOUR: Désolé, n'a pas vraiment répondu à la question, a raccroché sur l'utilisation de la terminologie "RESTful". Si vous parlez seulement des avantages des URL propres (argument REST/SOA mis à part), l'argument typique est une meilleure optimisation du référencement et de la convivialité (l'utilisateur peut mieux comprendre et modifier les URL).

+0

Les verbes http ne sont pas du tout CRUD. Voir http://www.innoq.com/blog/st/2007/04/rest_is_not_crud.html – SerialSeb

+0

"Être RESTful est plus que de simplement avoir des URL propres." Voilà le cœur de ma question. Je commence à comprendre les implications architecturales, mais du point de vue des RIA, et dans mon cas avec une application Web basée sur MVC, je remets en question les avantages que je devrais attendre d'essayer une approche reposante. Peut-être que les seuls avantages sont ce que vous listez dans votre édition, ce qui est très bien, puisque mes sponsors d'affaires n'ont pas l'obligation de fournir d'autres points d'accès dans l'application en plus de l'interface Web. Hmmm, matière à réflexion ... – nkirkes

+0

Peut-être une meilleure question pour faire avancer la conversation est "quand restez-vous fidèle à REST, et quand décidez-vous de passer à une architecture basée sur SOAP?" Le temps de conception est probablement le meilleur endroit pour prendre cette décision, mais si vous êtes à mi-parcours et que vous étiez auparavant dans l'ignorance? – nkirkes

1

l'avantage est que si vous avez une adresse et à partir de cette adresse que vous obtenir quelque chose, vous pouvez appeler cette adresse où que vous voulez dans votre code, et vous obtiendrez exactement la même chose :)

et exemple concret, si vous avez un chemin qui peut renvoyer du HTML complet avec des données (contrôle utilisateur par exemple), alors vous pouvez l'appeler depuis ajax, depuis votre application de bureau ou même depuis votre service web ... c'est très puissant car vous allez avoir certaines fonctionnalités répétées sur votre application ... et parce que certains html que vous obtenez de ce service reposant vous donnant exactement une vue avec exactement une fonctionnalité, vous pouvez l'appeler dynamiquement à partir de dialogue ou de la page ou de votre application de bureau ou de n'importe où. .. et quand vous ajoutez à cela que vous pouvez appeler cette adresse avec des paramètres, exactement comme une méthode, vous pouvez voir comment powerfull cela peut être dans la création de pages dynamiques et des sites web/systèmes

this helps

Questions connexes