Ir para o conteúdo principal

Definir padrões de resposta nas APIs desenvolvidas em Javascript

Data de elaboração 02/07/22
Responsável pelo estudo
  1. Igor Ramos de Oliveira (Assessor)
Equipe do estudo Esquadrão Suicida
Alvo e-Estado APIs
Origem

 

  • Objetivo estratégico: Necessidade de padronizar as respostas de APIs feitas com javascript.
Objetivo Definir padrões de retorno das APIs desenvolvidas em Javascript a fim de facilitar o consumo das mesmas sem a necessidade de ter que se adequar à estruturas diferentes.
Documentação correlata (opcional)

 

Observações Não possui.

1. Introdução

Os retornos das APIs, em geral, não segue um padrão pois não há um consenso sobre como esse retorno deve ser, isto porque a responsabilidade é de cada pessoa/equipe/empresa definir a forma que melhor lhe atende.

A importância dessa definição se dá pelo fato de ter que se adequar apenas um vez. Assim, sempre que uma nova API for consumida, o consumidor já tem o conhecimento de como é a estrutura base da resposta.

2. Desenvolvimento

Para a definição do padrão da retorno, primeiro é necessário identificar os tipos possíveis de retorno, eles podem ser:

  • Uma lista de objetos com paginação
  • Uma lista de objetos sem paginação
  • Um único objeto
  • Erros

A seguir é exibido os modelos propostos para cada tipo (os dados utilizados são apenas para exemplificar).

2.1 Uma lista de objetos com paginação

Para esse caso, o seguinte modelo é proposto:

image.png

2.2 Uma lista de objetos sem paginação

Para esse caso, o seguinte modelo é proposto:

image.png

2.3 Um único objeto

Para esse caso, o seguinte modelo é proposto:

image.png

2.4 Erros

Para esse caso, o seguinte modelo é proposto:

2.4.1 ValidationError

Erros de validação de campo

image.png

2.4.2 RuleError

Erros de regra de negócio

image.png


Com os modelos propostos é possível definir padrões para os mais diversos casos de respostas, tendo em vista a obter um padrão que possa mudar no futuro.

3. Conclusão

É possível concluir que um padrão de resposta é muito importante, e que com ele elimina a necessidade de retrabalho/readequação ao consumir uma nova API. O padrão proposto atende perfeitamente, até então, as mais diversas necessidades e portanto não há impedimentos para sua utilização.