Ce qui est tellement Reposant sur ASP.NET MVC?

Question

Le REPOS a été un mot à la mode populaire pour les deux dernières années (ou presque) et quand ASP.NET MVC sorti, tout le monde était relatives REPOS avec ASP.NET MVC. J'ai aussi craqué pour le buzz, et de l'absence de mes connaissances, de ma compréhension de REPOS a été tout simplement:

REPOS = SEO/User friendly URLs

Mais c'est tellement plus. Et plus j'en apprends sur le REPOS du moins je rapporte ASP.NET MVC avec elle. Bien entendu, il est beaucoup plus proche de RESTE que WebForms. Donc, la vérité est en fait tout à fait le contraire:

RESTE ≠ SEO/User friendly URLs

Et d'avoir votre route par défaut définie comme controller/action/id est certainement pas de tout repos.

Laissez-moi vous expliquer mon problème avec cette compréhension.

Si ASP.NET MVC a été Reposante, nous n'aurions pas de route par défaut définie comme:

controller/action/id

mais plutôt

resources/id  /* that would have to use HTTP methods GET/PUT/POST/DELETE */

Alors au lieu d'avoir (aussi fournir une méthode HTTP à demander le chemin d'accès):

/product/index/1  /* GET */
/product/create   /* POST */
/product/delete/1 /* POST */
/product/update/1 /* POST */

il devrait être (méthode HTTP fournis ici)

/products/1  /* GET */
/products    /* POST */
/products/1  /* DELETE */
/products/1  /* PUT */

Maintenant, ce serait Reposant. La bonne chose est que ce qui est réellement possible. Et si vous voulez le rendre totalement Reposant cela signifie également que vous devez avoir à utiliser Ajax parce que les méthodes PUT et DELETE ne peut pas être fait avec un navigateur uniquement les demandes (ce n'est pas tout à fait vrai¹). Tellement moderne des applications Ajax peut effectivement être complètement Détendu.

Ajax est client de la technologie et de ne pas vraiment avoir rien à faire avec ASP.NET MVC. Le fait est que ASP.NET MVC peut être fait entièrement Reposant application. Les moyens de l'atteindre (Ajax) n'est pas important. (merci à Darin Dimitrov)

La question principale

Pourquoi ne nous considérons ASP.NET MVC comme un cadre Reposant notamment sur son routage d'URL? Pourquoi n'ont-ils pas définir l'URL par défaut de l'itinéraire pour appliquer de la Détente? Je ne suis pas à la recherche pour argumentatif de réponses, mais ceux qui ont réellement répondre à la question - comment ce rapport de venir dans la vie... Peut-être que je ne suis pas encore assez sage et toujours prendre ce que l'absence de mes connaissances sur les deux.

¹mise à Jour de l'info

En fait, vous n'avez pas à utiliser Ajax pour mettre pleinement en œuvre Reposant architecture. Asp.net MVC prend en charge (depuis la version 2) HTTP redéfinition de méthode, ce qui signifie que vous pouvez question de METTRE ou SUPPRIMER des méthodes à l'aide de formulaires de navigateur. Tout ce que vous avez à faire est d'ajouter un champ caché comme:

<input type="hidden" name="X-HTTP-Method-Override" value="DELETE" />

Asp.net framework MVC sera en mesure de comprendre ce genre de POST demande comme une demande de SUPPRESSION et d' HttpDeleteAttribute action sélecteur de la méthode sera aussi la comprendre comme une demande de suppression. HTTP redéfinition de Méthode FTW!

Answer 1

Il n'y a rien qui vous empêchent de vivre routes, comme resource/id avec les méthodes HTTP GET/PUT/POST/DELETE dans ASP.NET MVC. Ce n'est pas les routes par défaut de l'installation, mais vous pouvez le faire.

EDIT (MLaritz - Ajout de Darin commentaire): ASP.NET MVC est un serveur de côté la technologie vous permettant d'exposer Reposant url. La façon dont ils sont consommés n'a pas d'importance. Vous m'avez demandé pourquoi ASP.NET MVC est considéré comme Reposant technologie et la réponse est parce que vous pouvez facilement exposer Reposant url pour la consommation, c'est aussi simple que cela.

Answer 2

Je pense que beaucoup de buzz avait plus à voir avec la façon dont l'onu-Sommeil le .NET web de la pile avant de MVC et comment beaucoup plus facile MVC fait pour construire des applications Reposant sur l' .NET plate-forme que n'importe quel particulièrement Reposants capacités ASP.NET MVC.

Answer 3

Il n'y a pas d'URI style qui rend une API restful.

Vous l'avez demandé, "Pourquoi ne nous considérons ASP.NET MVC comme un cadre Reposant notamment sur son routage d'URL? "

Parce que le REPOS est mal compris à propos des Url au lieu de ressources, une interface standard, et hypermédia.

Answer 4

Ce lien pourrait vous éclairer dans votre quête ... eh bien, en bref, vous pouvez avoir des Urls comme vous le décrivez - au moins avec MVC 2.

Answer 5

J'ai juste pensé à contribuer pour le RESTE de la discussion sur l'utilisation de PUT et DELETE.

En général, dans le REPOS et l'autre Reposant cadres, la question de PUT et DELETE n'est pas résolu en faisant des Url de la forme resource/create ou resource/delete. Plutôt, le verbe est dissimulé par la POSTE par:

1. Le passage d'un caché d'entrée dans un formulaire HTML, comme _method.
2. L'utilisation de JavaScript pour faire le PUT ou DELETE
3. Pour surmonter certains pare-feu, vous devrez peut-être utiliser le HTTP X-HTTP-Method-Override - tête.

C'est une solution générale pour la question des méthodes HTTP.

Je ne suis pas informé ASP.Net de dire pourquoi ils n'ont pas pris de cette façon, mais une URL de la forme /product/delete/1 ne fournissent pas une bonne ressource.

Edit: Un peu de précisions sur ce qu'est le RESTE semble être nécessaire. De la bouche des chevaux:

Une API REST ne doit pas contenir de tous les changements pour les protocoles de communication à part de remplir ou de fixer les détails de underspecified bits de protocoles tels que HTTP PATCH de la méthode ou le Lien de champ d'en-tête. Des solutions de contournement pour cassé les implémentations (tels que les navigateurs assez stupide pour croire que le langage HTML définit l'adresse HTTP de la méthode d'ensemble) doit être définie séparément, ou au moins dans les annexes, avec l'espoir que la solution sera finalement obsolète. [Défaut ici implique que la ressource interfaces sont spécifiques à l'objet, et non générique.]

C'est moi qui souligne. Le REPOS n'est pas définie comme l'aide des quatre méthodes HTTP. Il n'est même pas défini comme utilisant le protocole HTTP. Il a besoin d'un protocole de communication avec la capacité de suivre les liens hypertexte. Et il utilise ce protocole, avec des définitions ajouté, sans violer le protocole.

Dans le cas de HTTP, en utilisant les solutions de contournement pour les navigateurs qui ne mettent pas en œuvre PUT et DELETE est explicitement autorisé. Les Rails de la méthode dans le point 1 n'est manifestement qu'.