| ... | ... | @@ -13,6 +13,7 @@ Esta página centraliza informações sobre o [repositório Backend do projeto S |
|
|
|
- [Nomenclatura de variáveis](#nomenclatura-de-variáveis)
|
|
|
|
- [Nomenclatura de métodos](#nomenclatura-de-métodos)
|
|
|
|
- [Tratamento de exceções](#tratamento-de-exceções)
|
|
|
|
- [Validação de parâmetros das requisições](#validação-de-parâmetros-das-requisições)
|
|
|
|
- [Documentação do Swagger](#documentação-do-swagger)
|
|
|
|
|
|
|
|
## Organização do repositório
|
| ... | ... | @@ -87,8 +88,56 @@ Além disso, para facilitar a leitura do código, em uma classe os métodos semp |
|
|
|
|
|
|
|
## Tratamento de exceções
|
|
|
|
|
|
|
|
TODO
|
|
|
|
No projeto, dentro do pacote `config`, existe a classe `GlobalExceptionHandler`, que foi criada para que as exceções lançadas pela a aplicação durante a execução sejam tratadas e retornadas com um corpo de resposta e status HTTP de resposta apropriados.
|
|
|
|
|
|
|
|
Em casos de erro, o corpo da resposta deve sempre seguir um formato padronizado, conforme exemplo abaixo. Este formato é aquele modelado pela classe `ErrorResponse`.
|
|
|
|
```json
|
|
|
|
{
|
|
|
|
"error": "Mensagem da excecao"
|
|
|
|
}
|
|
|
|
```
|
|
|
|
|
|
|
|
Para garantir que esse padrão seja seguido para as diferentes exceções que possam ocorrer, foi criado um método genérico para tratamento de exceção nesta classe `GlobalExceptionHandler` onde, ao ser lançada uma exceção do tipo `HttpException`, retorna-se uma resposta com a mensagem e o status HTTP que são atributos desta classe.
|
|
|
|
|
|
|
|
Ou seja, novas exceções criadas dentro do pacote `exception` devem ser subclasses da classe pai `HttpException`, e devem informar no construtor o status HTTP a ser retornado e a mensagem de erro. Assim, será feito o tratamento descrito acima sem precisar de nenhum código adicional.
|
|
|
|
|
|
|
|
Para mais informações, leia [esta documentação do Spring](https://spring.io/blog/2013/11/01/exception-handling-in-spring-mvc).
|
|
|
|
|
|
|
|
## Validação de parâmetros das requisições
|
|
|
|
|
|
|
|
Ao receber uma nova requisição, é importante verificar se os parâmetros necessários vieram preenchidos de forma completa e com valores que façam sentido. Uma forma na qual se pode fazer isso é utilizando a API de validação de Beans do Java.
|
|
|
|
|
|
|
|
A API disponibiliza várias anotações que podem ser utilizadas para validar diferentes cenários, a exemplo de:
|
|
|
|
- @NotNull: verifica se a variável/atributo é nulo.
|
|
|
|
- @NotBlank: verifica se a variável/atributo String é nulo ou é uma String vazia.
|
|
|
|
- @Min: verifica se a variável/atributo tem valor igual ou maior que o valor mínimo informado.
|
|
|
|
- @Max: verifica se a variável/atributo tem valor igual ou menor que o valor máximo informado.
|
|
|
|
|
|
|
|
Supondo um cenário onde existe um *endpoint* de uma aplicação de biblioteca, para registro de novos livros, onde se recebe um corpo de requisição JSON, para realizar a validação precisariam ser feitos os ajustes abaixo:
|
|
|
|
1. Na classe DTO que modela os dados do corpo da requisição, adicionar as anotações nos atributos que se deseja validar.
|
|
|
|
```java
|
|
|
|
public class BookRequest {
|
|
|
|
@NotBlank(message = "Titulo precisa ser informado.")
|
|
|
|
private String title;
|
|
|
|
@NotBlank(message = "Autor precisa ser informado.")
|
|
|
|
private String author;
|
|
|
|
@Min(value = 1, message = "Ano de lancamento precisa ser valido.")
|
|
|
|
private Integer releaseYear;
|
|
|
|
}
|
|
|
|
```
|
|
|
|
2. Adicionar a anotação @Valid no método do controller onde se recebe o corpo da requisição.
|
|
|
|
```java
|
|
|
|
@PostMapping
|
|
|
|
public BookResponse createBook(@Valid @RequestBody BookRequest bookRequest) {
|
|
|
|
...
|
|
|
|
}
|
|
|
|
```
|
|
|
|
Para mais informações, leia [esta página](https://www.baeldung.com/java-validation).
|
|
|
|
|
|
|
|
## Documentação do Swagger
|
|
|
|
|
|
|
|
TODO |
|
|
|
A ferramenta Swagger (OpenAPI) já foi configurada na aplicação, para documentação da API e para permitir testar requisições HTTP via interface gráfica. Diante disso, novos *controllers* REST que forem criados já vão ser exibidos na [url do Swagger](http://localhost:8080/swagger-ui/index.html) sem precisar de nenhuma configuração adicional.
|
|
|
|
|
|
|
|
No entanto, para garantir que a API esteja bem documentada, sugere-se utilizar as anotações da API do Swagger para descrever melhor quais são os propósitos de cada *endpoint* e quais são os significados de cada parâmetro de requisição e código de resposta.
|
|
|
|
|
|
|
|
Para mais informações, leia [esta página](https://springdoc.org/v1/). |
|
|
\ No newline at end of file |
