O simples bem feito

Com uma quantidade enorme de frameworks e tecnologias, a vontade maior dos desenvolvedores é utilizá-los para facilitar o desenvolvimento e gerar uma melhor usabilidade. Porém não é bem assim que funciona, ainda hoje o melhor é buscar pela simplicidade, o “simples bem feito” trará uma boa usabilidade e performance em suas aplicações. Sendo assim, deixo alguns pontos para observar durante o desenvolvimento de API’s REST buscando a simplicidade e qualidade:

Evitar representações de tabelas: A principal função da API é expor dados, mas não é necessário expor exatamente a entidade do banco de dados, apenas aquelas informações que são necessárias para o processo. Sempre simplificar as informações, evitar agregação e agrupamento, isso irá simplificar o código, deixa mais objetivo e facilita o consumo das informações.

Contrato base: A utilização de um retorno genérico também pode ser usado para padronizar o retorno das solicitações. Por exemplo, o retorno de todos os endpoints da sua API ira retornar um objeto genérico, contendo campos de status, código, mensagem e um campo para o tipo do retorno solicitado (payload). Ex.:

Convenções de casing: A utilização de casing é algo recomendado para qualquer tipo de projeto, não só para API’s, isso irá melhorar a legibilidade do código, seguirá um padrão e a colaboração será mais efetiva.

Porém não há uma convenção melhor que outra, geralmente é definido pela equipe que irá atuar no projeto, a mais utilizada atualmente é o camelCase, onde a primeira letra é minúscula, e caso exista uma segunda palavra, inicia-se com letra maiúscula, sem espaçamento.

Outros exemplos são:

PascalCase

snake_case

kebab-case

Definição de rotas: Durante a criação das rotas, não é recomendado utilizar o nome das ações, e sim o nome que represente as entidades utilizadas nas requisições. As ações serão definidas pelo verbo HTTP utilizado:

POST: cria uma entidade;

GET: recebe dados da entidade;

PUT/PATCH: Atualiza uma entidade;

DELETE: exclui uma entidade.

Ex.:

Ruim: POST api/addNewCustomer

Bom: POST api/customer

Todas as rotas possuirão códigos de status das respostas HTTP que indicam se uma requisição foi atendida com sucesso. Esses status são agrupados em cinco categorias:

Respostas de informação (100 - 199)

Respostas de sucesso (200 - 299)

Redirecionamentos (300 - 399)

Erros do cliente (400 - 499)

Erros do servidor (500 - 599)

Esses são alguns pontos que acredito que trará uma melhor legibilidade, usabilidade e colaboração em desenvolvimento de API’s REST, lógico, existem muitas outras formas de seguir, não se deve tomar esses pontos como lei, sempre deve ser alinhado com todos os desenvolvedores envolvidos no processo, mas se não sabe por onde começar, esses pontos já podem ser usados como base.

Gostou?? Entre em contato pelo LinkedIn: linkedin.com/in/marcelo-montalvao/