Existem algumas diferenças entre a rota de listagem de todos os dados e da listagem específica. Entre elas, as duas que se destacam são:
- Precisamos receber um parâmetro indicando qual objeto retoranr
- Precisamos verificar se o objeto existe ou não para que seja retornada uma mensagem de erro.
Uma rota para retornar um objeto do tipo Palavra
, sendo especificado pelo seu id
recebe a seguinte anotação:
[HttpGet]
[Route("{id}")]
public async Task Palavra GetPalavra(int id)
{
...
}
Estamos dizendo pro ASP.NET core que nossa rota irá receber um parâmetro, que estamos chamando de id. Isso pois, caso queiramos retornar a palavra com id 2, iremos realizar uma chamada na rota /api/Palavras/2
.
No exemplo acima, dizemos então que a rota recebe um atributo chamado id. Esse atributo é passado como argumento do método de nossa rota, nesse caso int id
. Através dessa variável, podemos realizar diversas ações específica a essa rota. No código abaixo, vemos um exemplo simples de retornar uma Palavra por id.
[HttpGet]
[Route("{id}")]
public async Task ActionResult<Palavra> GetPalavra(int id)
{
try
{
var palavra = await _repository.GetPalavraPorId(id);
return palavra;
}
catch (Exception)
{
return this.StatusCode(StatusCodes.Status500InternalServerError, "Database failure");
}
}
Retornando Not Found
O código acima possuí um problema. No caso de não haver uma palavra com o id
recebido, é retornado o código HTTP 204: No Content
O correto seria retornar uma mensagem de erro para o cliente, com o retorno 404 Not Found
. Sabemos que existe um método que retorna esse erro, o NotFoun()
, basta então checarmos no controller se o retorno do banco está vazio ou não
[HttpGet]
[Route("{id}")]
public async Task ActionResult<Palavra> GetPalavra(int id)
{
try
{
var palavra = await _repository.GetPalavraPorId(id);
if (palavra == null) return NotFound();
return palavra;
}
catch (Exception)
{
return this.StatusCode(StatusCodes.Status500InternalServerError, "Database failure");
}
}
Nosso código agora, irá retornar o erro 404 caso a Palavra não seja encontrada no banco de dados, junto de um JSON que segue a RFC 7807.
{
"type": "https://tools.ietf.org/html/rfc7231#section-6.5.4",
"title": "Not Found",
"status": 404,
"traceId": "|6b16da39-47c24449f9eb6854."
}
E, como antes, no caso do método ser executado com sucesso, é retornado nosso objeto em JSON com o código HTTP 200: OK.
Exceptions
Uma boa prática de quando acontecer uma exception é realizar um log dela e retornar um erro 500. Para isso, capturamos a exception e escrevemos no log. Isso pode ser feito tanto no catch
quanto em um filtro que captura exceptions.
O cliente então irá receber um código 500 caso ocorra algum erro interno. Se formos lançar essa exception, a aplicação irá ser suspendida, o que não seria uma boa ideia. Exceptions podem ser erros como um banco de dados indisponível, onde não temos controler por ser algo inesperado.
Fontes
https://docs.microsoft.com/pt-br/aspnet/core/mvc/controllers/routing?view=aspnetcore-5.0#ar
http://www.macoratti.net/19/06/aspnc_3dwebapi1.htm
https://docs.microsoft.com/pt-br/aspnet/core/mvc/controllers/filters?view=aspnetcore-5.0#exception-filters
Top comments (0)