Comment une méthode MVC WebApi carte à un verbe http?

Je m'excuse à l'avance, ce post s'éloigne un peu de ce que vous avez demandé, mais tout cela bouillonnait quand j'ai lu votre question.

WebAPI Appariement Sémantique

L'appariement sémantique utilisé par (le par défaut routes) WebAPI est assez simple.

1. Il correspond au nom de l'action avec le verbe (verbe = GET? recherchez le nom de la méthode en commençant par "get")
2. si un paramètre est passé, l'api cherche une action avec un paramètre

Donc dans votre exemple de code d'une requête GET sans paramètre correspond à la Get*( ) fonction sans paramètres. Un contenant et ID recherche un Get***(int id).

Exemples

Alors que l'appariement sémantique est simple, elle crée une certaine confusion pour MVC développeurs (bien au moins ce développeur). Regardons quelques exemples :

Bizarre Noms - Votre méthode get peut être nommé n'importe quoi, tant que ça commence par "get". Ainsi, dans le cas d'un widget contrôleur, vous pouvez nommer vos fonctions GetStrawberry() et il sera toujours appariés. Pensez à la correspondance que quelque chose comme : methodname.StartsWith("Get")

Plusieurs Méthodes d'Appariement - Ce qui arrive si vous disposez de deux méthodes Get sans paramètres? GetStrawberry() et GetOrange(). Du mieux que je peux dire, la fonction définie à la première (en haut du fichier) dans votre code gagne ...étrange. Cela a pour effet secondaire de faire certaines méthodes dans votre contrôleur inaccessible (au moins avec les routes par défaut)....étranger.

NOTE : la bêta se sont comportés comme ci-dessus pour la correspondance de multiples méthodes " - le RC & version est un peu plus trouble obsessionnel-compulsif. Il renvoie une erreur si il y a plusieurs correspondances possibles. Cette modification supprime la confusion de plusieurs ambigu matchs. Dans le même temps, il réduit notre capacité à mélanger les REPOS et RPC interfaces de style dans le même contrôleur, en s'appuyant sur l'ordre & le chevauchement des routes.

Que faire?

Eh bien, WebAPI est nouveau, et le consensus est toujours la coalescence. La communauté semble être atteint pour le REPOS des principes tout à fait un peu. Pourtant, pas tous les API peut ou devrait être paisible, certains sont plus naturellement exprimée dans un style RPC. RESTE & que les gens appellent le RESTE semble être la source de un peu de la confusion, bien au moins à Roy Fielding.

Comme un pragmatique, je pense que nombre d'API sera de 70% Reposante, avec une poignée de type RPC méthodes. Tout d'abord, le contrôleur de la prolifération seul (compte tenu de la webapi méthode de reliure) va conduire les développeurs de dingue. Deuxièmement, WebAPI n'a pas vraiment intégré dans la façon de créer une structure imbriquée des api chemins (ce qui signifie: /api/controller/ est facile, mais /api/CATEGORY/Sub-Category/Controller est faisable, mais une douleur).

De mon point de vue, j'aimerais voir la webAPI structure de dossier de contrôle de la valeur par défaut de l'API chemins... de sens que si je créer un dossier de Catégorie dans mon INTERFACE puis /api/Category serait le chemin d'accès par défaut (quelque chose parallèlement à cette MVC article).

Qu'ai-je fait?

Donc, j'avais quelques exigences: (1) pour être en mesure d'utiliser reposant syntaxe dans la plupart des cas, (2) d'avoir un peu d'espace de noms" séparation des contrôleurs (pensez à les sous-dossiers), (3) être en mesure d'appeler d'autres rpc-comme des méthodes si nécessaire. La mise en œuvre de ces exigences est descendu à intelligent de routage.

//SEE NOTE AT END ABOUT DataToken change from RC to RTM

Route r;
r = routes.MapHttpRoute( name          : "Category1", 
                         routeTemplate : "api/Category1/{controller}/{id}", 
                         defaults      : new { id = RouteParameter.Optional } );
r.DataTokens["Namespaces"] = new string[] {" UI.Controllers.Category1"};

r = routes.MapHttpRoute( name          : "Category2", 
                         routeTemplate : "api/Category2/{controller}/{id}", 
                         defaults      : new { id = RouteParameter.Optional } );
r.DataTokens["Namespaces"] = new string[] {" UI.Controllers.Category2"};

routes.MapHttpRoute(     name          : "ApiAllowingBL", 
                         routeTemplate : "api/{controller}/{action}/{id}",
                         defaults      : new { id = RouteParameter.Optional } );

routes.MapHttpRoute(     name          : "DefaultApi",  
                         routeTemplate : "api/{controller}/{id}",           
                         defaults      : new { id = RouteParameter.Optional } );

• Les deux premières voies de créer des "sous-dossier" routes. J'ai besoin de créer une route pour chaque sous-dossier, mais je me suis restreint à grandes catégories, alors je n'en ai jusqu'à la fin avec 3-10 de ces. Remarquez comment ces routes ajouter le Namespace données jeton, pour limiter ce que les classes sont recherchées pour un itinéraire particulier. Cela correspond bien aux caractéristiques de l'espace de noms de la configuration que vous ajouter des dossiers à la une de l'INTERFACE.
• La troisième voie permet à des noms de méthodes pour être appelé (comme mvc traditionnel). Depuis l'API web fait disparaître le nom de l'action dans l'URL, il est relativement facile de savoir qui appelle souhaitez que cette route.
• La dernière entrée de gamme est le site web par défaut de l'api de la route. Ce prises toutes les classes, en particulier ceux qui sont en dehors de mon "sous-dossiers".

Dit D'Une Autre Manière

Ma solution est venue vers le bas pour séparer les contrôleurs un peu plus /api/XXXX n'ai pas trop encombré.

• J'ai créer un dossier dans mon INTERFACE(disons Category1), et de mettre contrôleurs d'api dans le dossier.
• Visual studio naturellement définit la classe des espaces de noms basés sur le dossier. Donc Widget1 dans le Category1 dossier devient un espace de noms par défaut de UI.Category1.Widget1.
• Naturellement, j'ai voulu Url de l'api afin de refléter la structure de dossier (/api/Category1/Widget). La première carte que vous voyez ci-dessus accomplit que par le codage en dur des /api/Category1 dans la route, puis la namespace jeton restreint de classes qui vont être recherchés pour la correspondance du contrôleur.

NOTE: de la version DataTokens ont la valeur null par défaut. Je ne suis pas
sûr que si c'est un bug ou une fonctionnalité. J'ai donc écrit une petite aide
méthode et ajouté à mon RouteConfig.cs fichier....

r.AddRouteToken("Namespaces", new string[] {"UI.Controllers.Category1"});

private static Route AddRouteToken(this Route r, string key, string[] values) {
  //change from RC to RTM ...datatokens is null
if (r.DataTokens == null) {
       r.DataTokens = new RouteValueDictionary();
    }
    r.DataTokens[key] = values;
    return r;
}

NOTE 2: même pensé que c'est une WebAPI 1 poste, comme @Jamie_Ide points dans les commentaires de la solution ci-dessus ne fonctionne pas dans WebAPI 2 parce que IHttpRoute.DataTokens n'a pas de setter. Pour contourner cela, vous pouvez utiliser une simple extension de la méthode comme ceci:

private static IHttpRoute MapHttpRoute(this HttpRouteCollection routes, string name, string routeTemplate, object defaults, object constraints, string[] namespaceTokens)
{   
    HttpRouteValueDictionary    defaultsDictionary      = new HttpRouteValueDictionary(defaults);
    HttpRouteValueDictionary    constraintsDictionary   = new HttpRouteValueDictionary(constraints);
    IDictionary<string, object> tokens                  = new Dictionary<string, object>();
                                tokens.Add("Namespaces", namespaceTokens);

    IHttpRoute route = routes.CreateRoute(routeTemplate, defaultsDictionary, constraintsDictionary, dataTokens: tokens, handler:null);
    routes.Add(name, route);

    return route;
}