Dans l'API Web, j'avais une classe de structure similaire :
public class SomeController : ApiController
{
[WebGet(UriTemplate = "{itemSource}/Items")]
public SomeValue GetItems(CustomParam parameter) { ... }
[WebGet(UriTemplate = "{itemSource}/Items/{parent}")]
public SomeValue GetChildItems(CustomParam parameter, SomeObject parent) { ... }
}
Comme nous pouvions mapper les méthodes individuelles, il était très simple d'obtenir la bonne requête au bon endroit. Pour une classe similaire qui n'avait qu'une seule GET
mais dispose également d'une méthode Object
j'ai utilisé avec succès le paramètre IActionValueBinder
. Cependant, dans le cas décrit ci-dessus, j'obtiens l'erreur suivante :
Multiple actions were found that match the request:
SomeValue GetItems(CustomParam parameter) on type SomeType
SomeValue GetChildItems(CustomParam parameter, SomeObject parent) on type SomeType
J'essaie d'aborder ce problème en surchargeant la fonction ExecuteAsync
méthode de ApiController
mais sans succès jusqu'à présent. Un conseil sur ce problème ?
Edit : J'ai oublié de mentionner que j'essaie maintenant de déplacer ce code sur ASP.NET Web API qui a une approche différente du routage. La question est la suivante : comment faire fonctionner le code sur ASP.NET Web API ?
1 votes
Avez-vous toujours le {parent} comme RouteParameter.Optional ?
0 votes
Oui, je l'ai fait. Peut-être que j'utilise IActionValueBinder de la mauvaise façon, car pour des types tels que int id (comme dans la démo), cela fonctionne bien.
0 votes
Désolé, j'aurais dû être plus clair. J'aurais pensé que le fait qu'il soit facultatif signifiait qu'il correspondait à la route des éléments ainsi qu'à celle des sous-éléments, ce qui expliquerait le message d'erreur que vous voyez.
0 votes
Nous discutons actuellement de la question de savoir si les approches ci-dessous (avec des routes multiples) sont contraires aux règles REST appropriées ? À mon avis, c'est très bien. Mon collègue pense que ce n'est pas bien. Des commentaires à ce sujet ?
0 votes
J'étais généralement contre lorsque j'ai commencé à lire sur REST. Je ne suis toujours pas sûr qu'il s'agisse d'une approche appropriée, mais parfois, elle est plus pratique ou plus conviviale, de sorte qu'une légère entorse aux règles n'est peut-être pas si mauvaise. Tant que cela permet de résoudre un problème spécifique. Six mois se sont déjà écoulés depuis que j'ai posté cette question et nous n'avons pas regretté d'avoir utilisé cette approche depuis.
0 votes
Assurez-vous que vous modifiez WebApiConfig.cs pas RouteConfig.cs