¶ Definir padrões de resposta nas APIs desenvolvidas em Javascript.
| Data de elaboração | 02/07/22 |
| Responsável pelo estudo | 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 | |
| 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:
¶ 2.2 Uma lista de objetos sem paginação
Para esse caso, o seguinte modelo é proposto:
¶ 2.3 Um único objeto
Para esse caso, o seguinte modelo é proposto:
¶ 2.4 Erros
Para esse caso, o seguinte modelo é proposto:
¶ 2.4.1 ValidationError
Erros de validação de campo
¶ 2.4.2 RuleError
Erros de regra de negócio
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.