Plusieurs Types de contrôleurs avec le même préfixe de l'Itinéraire ASP.NET Web Api

Est-il possible de séparer les GETs et des Postes en différentes API Contrôleur de types et d'y accéder en utilisant le même Préfixe de l'Itinéraire?

Voici mon contrôleurs:

[RoutePrefix("api/Books")]
public class BooksWriteController : EventStoreApiController
{
    [Route("")]
    public void Post([FromBody] CommandWrapper commandWrapper){...}
}

[RoutePrefix("api/Books")]
public class BooksReadController : MongoDbApiController
{
    [Route("")]
    public Book[] Get() {...}


    [Route("{id:int}")]
    public Book Get(int id) {...}
}

OriginalL'auteur user1145404 | 2014-04-15

  1. 32

    Web de l'API (1.x-2.x) ne prend pas en charge plusieurs attributs les routes avec le même chemin sur les différents contrôleurs. Le résultat est une 404, parce que tout le parcours correspond à plus d'un contrôleur et à ce point de l'API Web examinera le résultat ambigu.

    Noter que MVC de Base prend en charge ce scénario remarque: MVC Cœur sert de MVC & Web API.

    Si vous choisissez d'utiliser l'API Web 2.11 (ou plus récent), vous pouvez créer un itinéraire contrainte pour la méthode http par contrôleur et de l'utiliser à la place de la construite en Route de l'Attribut. L'exemple ci-dessous montre que vous pouvez utiliser RoutePrefix ou directement Routes (comme kmacdonald de réponse).

    using System.Collections.Generic;
using System.Net.Http;
using System.Web.Http;
using System.Web.Http.Routing;

public class BooksWriteController : ApiController
{
    [PostRoute("api/Books")]
    public void Post() { }
}

[RoutePrefix("api/books")]
public class BooksReadController : ApiController
{
    [GetRoute]
    public void Get() { }

    [GetRoute("{id:int}")]
    public void Get(int id) { }
}

    Ces deux classes de simplifier l'utilisation de la contrainte de la route attribut

    class GetRouteAttribute : MethodConstraintedRouteAttribute
{
    public GetRouteAttribute(string template) : base(template ?? "", HttpMethod.Get) { }
}

class PostRouteAttribute : MethodConstraintedRouteAttribute
{
    public PostRouteAttribute(string template) : base(template ?? "", HttpMethod.Post) { }
}

    Cette classe permet d'ajouter des contraintes à la route généré

    class MethodConstraintedRouteAttribute : RouteFactoryAttribute
{
    public MethodConstraintedRouteAttribute(string template, HttpMethod method)
        : base(template)
    {
        Method = method;
    }

    public HttpMethod Method
    {
        get;
        private set;
    }

    public override IDictionary<string, object> Constraints
    {
        get
        {
            var constraints = new HttpRouteValueDictionary();
            constraints.Add("method", new MethodConstraint(Method));
            return constraints;
        }
    }
}

    C'est juste une route standard contrainte, nit: vous pouvez mettre en cache les contraintes de l'objet afin de réduire les allocations.

    class MethodConstraint : IHttpRouteConstraint
{
    public HttpMethod Method { get; private set; }

    public MethodConstraint(HttpMethod method)
    {
        Method = method;
    }

    public bool Match(HttpRequestMessage request,
                      IHttpRoute route,
                      string parameterName,
                      IDictionary<string, object> values,
                      HttpRouteDirection routeDirection)
    {
        return request.Method == Method;
    }
}
    Cela fonctionne parfaitement.
    aucune raison spécifique pour laquelle vous avez besoin de la coutume MethodConstraint ici au lieu de réutiliser Système.Web.Http.Le routage.HttpMethodConstraint?
    Le point est le fait de contraindre la route elle-même. La propriété intégrée n'agit que dans la sélection de l'action qui s'exécute trop tard.
    Dans le cas où quelqu'un est à la recherche à cette réponse et d'avoir des problèmes de nommage de l'itinéraire, puis la construction d'un itinéraire à l'aide de l'Url.Lien(...). Il y a une semblable réponse ici: stackoverflow.com/questions/40892637/... Les principales différences que j'ai vu étaient interfaces supplémentaires et l'utilisation de HttpMethodConstraint avec un tableau de HttpMethods. Quel que soit le cas, l'autre réponse permet à la route de nommage de toujours travailler à titre d'information.
    Hésitez pas à mettre à jour la réponse 🙂

    OriginalL'auteur Yishai Galatzer

  2. 4

    Vous n'avez pas toujours besoin de spécifier un RoutePrefix sur votre contrôleur. vous pouvez simplement mettre la route directement sur le web méthodes:

    public class BooksWriteController : EventStoreApiController
{
    [Route("api/Books")]
    public void Post([FromBody] CommandWrapper commandWrapper){...}
}

public class BooksReadController : MongoDbApiController
{
    [Route("api/Books")]
    public TaskTypeInfo[] Get() {...}


    [Route("api/Books/{id:int}")]
    public TaskTypeInfo Get(int id) {...}
}

    Cependant, j'imagine que votre RoutePrefix va fonctionner très bien sur les deux contrôleurs. Je pense que l'attribut RoutePrefix est utilisé en conjonction avec le Route attribut qui définit réellement la route. Cela signifie que tant que vous n'avez pas tout conflit entre les routes (c'est un biggie), vous devez être bien.

    Merci, c'est pas le problème. Le problème est de sélectionner le bon type de contrôleur basé sur GET ou POST

    OriginalL'auteur kmacdonald