2 min de leitura ·

Segredos de um JSON enigmático: explorando uma resposta de API curiosa

Sou dev PJ e trabalho com uma galera bem variada de clientes. Alguns deles usam um ERP bem famoso (não vou dar nomes, pra não complicar), mas que tem sua própria linguagem e... digamos, um estilo único de fazer APIs. Não sei se existe um clube secreto dos devs desse ERP onde eles decidem fazer as APIs no "modo difícil", ou se é tudo pra manter a gente entretido, vai saber.

Queria compartilhar com vocês uma resposta de API que recebi. Aviso: é forte. Olhem com cuidado para cada propriedade e tentem entender o padrão... se for possível.

{
    "Reservas": [
        {
            "cod-refer": "",
            "QtdeEstoque": 0.0,
            "Item-pai": "009027.00",
            "Cod-roteiro": "",
            "op-codigo": 10,
            "Partida": 5000,
            "Deposito": "PRO",
            "TipoControle": 3,
            "Oper": 10,
            "SemEstoque": "no",
            "Quant": 23.712,
            "Item": "039841",
            "Descricao": "REFIL 200gr STAND UP IMPORTADO",
            "Qtd Partidas": 780.0,
            "GECODIGO": "2",
            "Alternativo": "*",
            "Un": "KG",
            "DESTINO ": "1",
            "Unidade ": "CX"
        },
        {
            "cod-refer": "",
            "QtdeEstoque": 4854.0,
            "Item-pai": "009027.10",
            "Cod-roteiro": "",
            "op-codigo": 20,
            "Partida": 5000,
            "Deposito": "PRO",
            "TipoControle": 3,
            "Oper": 20,
            "SemEstoque": "no",
            "Quant": 152.0,
            "Item": "021984",
            "Descricao": "CAIXA N 24",
            "Qtd Partidas": 5000.0,
            "GECODIGO": "2",
            "Alternativo": "",
            "Un": "UN",
            "DESTINO ": "1",
            "Unidade ": "CX"
        }
    ]
}

Agora, algumas observações importantes que me deixaram intrigado:

Padrões de maiúsculas e minúsculas? Isso é para os fracos! Aqui temos QtdeEstoque, cod-refer, GECODIGO e por aí vai.
Estilos de nomenclatura variados: camelCase, kebab-case, UPPERCASE... Tudo junto e misturado. 🎉
Ah, e tem a famosa propriedade "Unidade " com um espaço no final. Porque, claro, encontrar isso na primeira tentativa seria fácil demais. 😅

Detalhe, isso acontece em todas API's do sistema, e até mesmo a mesma propriedade tem nomes bem diferentes em cada resposta.

Enfim, é só pra compartilhar mesmo.

LucasATS

1 mês atrás

trabalho em um sistema que possuí varios canais de dados, dados de shapefile, banco de dados de um lugar e de outro. enfim, varios cruzamentos, e da para notar isso ai, cada um tem um padraozinho, dai nós implementamos algumas funções para padronizar tudo, dai a api sai bonitinha pelo menos kkk.

só é chato que tem alguns dados DA MESMA API que te entragem coisas como UF da cidade, para alguns dados e ESTADO para outras, então, no final vc acaba tendo mts ifs :c

gpoleszuk

1 mês atrás

LucasATS, aos poucos as empresas estão se adequando que, em vez de utilizarem cidade e UF armazenados no banco de dados como composição char Cidade-UF, adotam um único inteiro de 7 dígitos que segue a proposta do IBGE.

Exemplo: 5002704
Cidade : Campo Grande - MS
Código : 50 02704
          |     |___ código da cidade (02704)
          |_________ código da Unidade da Federação (50)

Mais detalhes em https://www.ibge.gov.br/explica/codigos-dos-municipios.php

LucasATS

1 mês atrás

muito legal, não conhecia isso. obrigado.

tbm sou de campo grande-MS.

fabionaspolini

1 mês atrás

O padrão é não ter padrão, se criar muitas propriedades semelhantes nesse padrão, vc quebra os princípios do padrão e ficará despadronizado 🤪

oberdanbrito

1 mês atrás

Eu já vi isso antes. em minha cabeça imagino que cada dev que pegou no projeto usou o que mais gosta.
Acho que o líder fala: faz funcionar. não importa como

samuelcdias

1 mês atrás

Isso só me faz lembrar o quanto é importante ter camada de anti corruption

lucianoseibel

1 mês atrás

https://tdn.totvs.com/pages/viewpage.action?pageId=191467182

totvs cpapi013. ... reservas de materiais... trata-se de uma api do ems da antiga datasul q foi comprada pela tovs, nete caso nao usa linguagem própria do protheus, outro produto da tovs, e sim a usa progress. estes nomes tão discrepantes não são da base padrão das tabelas, ou melhor alguns são, os que tem hífen e lowercase, o restante é provindo de uma técnica de trabalho com progress que é o uso de temp tables para processamento na api e ai sim estas tenp tables estao sujeitas a toda ideia maluca de quem fez a api.

gpoleszuk

1 mês atrás

Se na verdade são padronizações exóticas e de uso exclusivo, mesmo que empregando o JSON como transporte estruturado, a situação apontada como "fora do comum" faz-me recordar de um artifício conhecido como "cidades de papel".

crafaelsdo

1 mês atrás

Eu acho que os padrões de nomeclatura misturados acontecerem porque vem de locais diferentes, por exemplo "cod-refer" parece algo que foi codado no backend enquanto "GECODIGO" parece ter vindo da BD, eu trabalho em uma distribuidora e as colunas das tabelas da DB do ERP são assim em uppercase, já a "Unidade " me parece que esta truncado... Será que não era pra ser "Unidade Master"? Onde trabalho usamos essa nomenclatura pra diferenciar da unidade de venda, por exemplo nós recebemos um produto em caixas com 24 unidades onde a "Unidade Master" é essa caixa com 24 e a "Unidade de venda" são cada um dos 24 itens dessa caixa.

igorwfaoro

Autor

1 mês atrás

Na vdd é exatamente isso hehe é aquele tipo de aplicação antiga toda baseada em banco de dados. Eu não atuo nesse back, mas de fato esses nomes vem do banco mesmo, até onde sei.