La version la plus basique répond avec un JsonResult
es:
// GET: api/authors
[HttpGet]
public JsonResult Get()
{
return Json(_authorRepository.List());
}
Toutefois, cela ne vous aidera pas à résoudre votre problème, car vous ne pouvez pas gérer explicitement votre propre code de réponse.
Pour contrôler les résultats de l'état, il faut renvoyer une valeur de type ActionResult
et c'est là que vous pouvez alors profiter de la StatusCodeResult
type.
par exemple :
// GET: api/authors/search?namelike=foo
[HttpGet("Search")]
public IActionResult Search(string namelike)
{
var result = _authorRepository.GetByNameSubstring(namelike);
if (!result.Any())
{
return NotFound(namelike);
}
return Ok(result);
}
Notez que les deux exemples ci-dessus proviennent d'un excellent guide disponible dans la documentation de Microsoft : Formatage des données de réponse
Extra Stuff
Le problème que je rencontre assez souvent est que je voulais un contrôle plus granulaire de ma WebAPI plutôt que de me contenter de la configuration par défaut du modèle "Nouveau projet" dans VS.
Assurons-nous que vous avez bien compris les principes de base...
Étape 1 : Configurez votre service
Pour que votre WebAPI ASP.NET Core réponde avec un objet sérialisé JSON tout en ayant le contrôle total du code d'état, vous devez commencer par vous assurer que vous avez inclus l'objet AddMvc()
dans votre ConfigureServices
que l'on trouve habituellement dans Startup.cs
.
Il est important de noter que AddMvc()
inclura automatiquement le formateur d'entrée/sortie pour JSON tout en répondant aux autres types de demandes.
Si votre projet nécessite contrôle total et que vous souhaitez définir strictement vos services, par exemple la manière dont votre WebAPI se comportera face à différents types de demandes, notamment application/json
et ne pas répondre à d'autres types de requête (comme une requête standard de navigateur), vous pouvez le définir manuellement avec le code suivant :
public void ConfigureServices(IServiceCollection services)
{
// Build a customized MVC implementation, without using the default AddMvc(), instead use AddMvcCore().
// https://github.com/aspnet/Mvc/blob/dev/src/Microsoft.AspNetCore.Mvc/MvcServiceCollectionExtensions.cs
services
.AddMvcCore(options =>
{
options.RequireHttpsPermanent = true; // does not affect api requests
options.RespectBrowserAcceptHeader = true; // false by default
//options.OutputFormatters.RemoveType<HttpNoContentOutputFormatter>();
//remove these two below, but added so you know where to place them...
options.OutputFormatters.Add(new YourCustomOutputFormatter());
options.InputFormatters.Add(new YourCustomInputFormatter());
})
//.AddApiExplorer()
//.AddAuthorization()
.AddFormatterMappings()
//.AddCacheTagHelper()
//.AddDataAnnotations()
//.AddCors()
.AddJsonFormatters(); // JSON, or you can build your own custom one (above)
}
Vous remarquerez que j'ai également inclus un moyen pour vous d'ajouter vos propres formateurs d'entrée/sortie personnalisés, dans le cas où vous voudriez répondre à un autre format de sérialisation (protobuf, thrift, etc.).
Le morceau de code ci-dessus est en grande partie une duplication de la fonction AddMvc()
méthode. Cependant, nous implémentons chaque service "par défaut" par nous-mêmes en définissant chaque service au lieu d'utiliser celui qui est déjà fourni avec le modèle. J'ai ajouté le lien du référentiel dans le bloc de code, ou vous pouvez vérifier AddMvc()
à partir du dépôt GitHub. .
Notez qu'il existe des guides qui tentent de résoudre ce problème en "annulant" les valeurs par défaut, plutôt que de ne pas les implémenter en premier lieu... Si vous tenez compte du fait que nous travaillons maintenant avec l'Open Source, c'est du travail redondant, du mauvais code et franchement une vieille habitude qui disparaîtra bientôt.
Étape 2 : Créer un contrôleur
Je vais vous en montrer un très simple, pour répondre à votre question.
public class FooController
{
[HttpPost]
public async Task<IActionResult> Create([FromBody] Object item)
{
if (item == null) return BadRequest();
var newItem = new Object(); // create the object to return
if (newItem != null) return Ok(newItem);
else return NotFound();
}
}
Étape 3 : Vérifiez votre Content-Type
y Accept
Vous devez vous assurer que votre Content-Type
y Accept
dans votre demande sont correctement configurés. Dans votre cas (JSON), vous voudrez le configurer pour qu'il soit application/json
.
Si vous souhaitez que votre WebAPI réponde en JSON par défaut, indépendamment de ce que l'en-tête de la requête spécifie, vous pouvez le faire dans un fichier de type deux façons .
Voie 1 Comme le montre l'article que j'ai recommandé précédemment ( Formatage des données de réponse ), vous pourriez forcer un format particulier au niveau du contrôleur/de l'action. Personnellement, je n'aime pas cette approche... mais la voici pour être complet :
Forcer un format particulier Si vous souhaitez restreindre les formats de réponse pour une action spécifique, vous pouvez appliquer le filtre filtre [Produces]. Le filtre [Produces] spécifie les formats de réponse de réponse pour une action (ou un contrôleur) spécifique. Comme la plupart des filtres, ce filtre peut être appliqué à l'action, au contrôleur ou à la portée globale.
[Produces("application/json")]
public class AuthorsController
El [Produces]
forcera toutes les actions dans le cadre de l AuthorsController
pour renvoyer des réponses au format JSON, même si d'autres formatters étaient configurés pour l'application et que le client fournissait une adresse Accept
demandant un format différent et disponible.
Voie 2 Ma méthode préférée est que l'interface WebAPI réponde à toutes les demandes avec le format demandé. Toutefois, au cas où elle n'accepterait pas le format demandé, il faudrait que l'API Web réponde à toutes les demandes avec le format demandé. solution de repli à une valeur par défaut (c'est-à-dire JSON).
Tout d'abord, vous devrez l'enregistrer dans vos options (nous devons retravailler le comportement par défaut, comme indiqué précédemment).
options.RespectBrowserAcceptHeader = true; // false by default
Enfin, en réorganisant simplement la liste des formateurs qui ont été définis dans le constructeur de services, l'hôte Web choisira par défaut le formateur que vous placez en haut de la liste (c'est-à-dire en position 0).
Vous trouverez de plus amples informations dans ce document Entrée du blog sur le développement et les outils Web .NET
1 votes
Les méthodes "ok" renvoient 200 comme code d'état. Les méthodes prédéfinies couvrent tous les cas courants. Pour retourner 201 (+en-tête avec le nouvel emplacement de la ressource), vous utilisez
CreatedAtRoute
méthode, etc.