Обязательность маршрутизации с помощью атрибутов
При наличии атрибута ApiController контроллер обязан использовать маршрутизацию с помощью атрибутов. Это просто принудительное применение того, что многие расценивают как установившуюся практику.
Автоматические ответы с кодом состояния 400
Если есть проблема с привязкой модели, то действие будет автоматически возвращать код состояния HTTP 400 (Bad Request), что заменяет следующий код:
if (!ModelState.IsValid)
{
return BadRequest(ModelState);
}
Для выполнения показанной выше проверки инфраструктура ASP.NET Core использует фильтр действий ModelStatelnvalidFilter. При наличии ошибок привязки или проверки достоверности ответ HTTP 400 в своем теле содержит детальные сведения об ошибках. Вот пример:
{
"type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
"title": "One or more validation errors occurred.",
"status": 400,
"traceId": "|7fb5e16a-4c8f23bbfc974667.",
"errors": {
"": [
"A non-empty request body is required."
]
}
}
Такое поведение можно отключить через конфигурацию в методе ConfigureServices() класса Startup:
services.AddControllers()
.ConfigureApiBehaviorOptions(options =>
{
options.SuppressModelStateInvalidFilter = true;
});
Выведение источников для привязки параметров
Механизм привязки моделей будет логически выводить источники извлечения значений на основе соглашений, описанных в табл. 30.1.
![]()
Такое поведение можно отключить через конфигурацию в методе Configure Services() класса Startup:
services.AddControllers().ConfigureApiBehaviorOptions(options =>
{
<b> // Подавить все выведение источников для привязки.</b>
<b> options.SuppressInferBindingSourcesForParameters= true;</b>
<b> // Подавить выведение типа содержимого multipart/form-data.</b>
<b> options. SuppressConsumesConstraintForFormFileParameters = true;</b>
(window.adrunTag = window.adrunTag || []).push({v: 1, el: 'adrun-4-390', c: 4, b: 390})
});
Детальные сведения о проблемах для кодов состояния ошибок
ASP.NET Core трансформирует результат ошибки (состояние 400 или выше) в результат с помощью типа ProblemDetails, который показан ниже:
public class ProblemDetails
{
public string Type { get; set; }
public string Title { get; set; }
public int? Status { get; set; }
public string Detail { get; set; }
public string Instance { get; set; }
public IDictionary<string, object> Extensions { get; }
= new Dictionary<string, object>(StringComparer.Ordinal);
}
Чтобы протестировать это поведение, добавьте в ValuesController еще один метод:
[HttpGet("error")]
public IActionResult Error()
{
return NotFound();
}
Запустите приложение и посредством пользовательского интерфейса Swagger выполните новую конечную точку error. Результатом по-прежнему будет код состояния 404 (Not Found), но в теле ответа возвратится дополнительная информация. Ниже приведен пример ответа (ваше значение traceId будет другим):
{
"type": "https://tools.ietf.org/html/rfc7231#section-6.5.4",
"title": "Not Found",
"status": 404,
"traceId": "00-9a609e7e05f46d4d82d5f897b90da624-a6484fb34a7d3a44-00"
}
Такое поведение можно отключить через конфигурацию в методе ConfigureServices() класса Startup:
services.AddControllers()
.ConfigureApiBehaviorOptions(options =>
{
<b> options.SuppressMapClientErrors = true;</b>
});
Когда поведение отключено, вызов конечной точки error возвращает код состояния 404 без какой-либо дополнительной информации.
Обновление настроек Swagger/OpenAPI
Продукт Swagger (также известный как OpenAPI) является стандартом с открытым кодом для документирования служб REST, основанных на API. Два главных варианта для добавления Swagger к API-интерфейсам ASP.NET Core — Swashbuckle и NSwag. Версия ASP.NET Core 5 теперь включает Swashbuckle в виде части шаблона нового проекта. Документация swagger.json, сгенерированная для AutoLot.Api, содержит информацию по сайту, по каждой конечной точке и по любым объектам, задействованным в конечных точках.
