Closed aivuk closed 9 years ago
Fiz uma primeira versão:
https://github.com/okfn-brasil/gastos_abertos/commit/f12ff95c0a2f5348d5650274ce2e2ed5ab2930a9#diff-564d372e4dad1244003538b7069729beR147
Mas não sei se é para dar uma "filter" mesmo, ou se há algo mais adaquado para o caso, já que code
é chave primária.
Com o código atual,
http://localhost:5000/api/v1/receita/code?code=1
Está me dando https://gist.github.com/9b1d3d254382b2a15eda , mas não sei se não é porque não estou conseguindo iniciar o BD.
Você tem que validar e transformar os argumentos de entrada! Note que ao configurar o argumento como:
revenue_code_parser.add_argument('code', action='append')
Você está dizendo que o argumento 'code' poderá ser passado mais de uma vez (&code='11'&code'12') e neste caso o tipo do argumento retornado pelo parser será uma lista. E mesmo neste caso você tem que lidar com os valores dessa lista, transformar em algo que faça sentido ser buscado no db. Se no db estiver:
'1774.0.0'
Você não poderá fazer uma query por '1774' obviamente.
Certo, vou ver isso. Um dúvida, você não colocou um '@restful.marshal_with' aqui: https://github.com/okfn-brasil/gastos_abertos/blob/master/gastosabertos/receita/views.py#L93 Mas fez isso na classe anterior. Está certo mesmo? Por quê?
Pronto, parece minimamento funcionar agora. Pelo menos para esse caso: http://localhost:5000/api/v1/receita/code?code=1.1.1.2
Dúvidas:
@aivuk ?
Sim, vamos receber mais de um code na entrada e retornar uma JSON contendo uma resposta pra cada code. E sim, vamos tratar o code de entrada, transformando-o para o formato que está na tabela RevenueCode, ou senão a busca não fará sentido.
Quoting aivuk (2015-02-06 10:48:02)
Sim, vamos receber mais de um code na entrada e retornar uma JSON contendo uma resposta pra cada code. Ok, feito.
E sim, vamos tratar o code de entrada, transformando-o para o formato que está na tabela RevenueCode, ou senão a busca não fará sentido. Hum, minha dúvida é sobre quais formatos vamos suportar...
Alterei o código para usar o mesma função de transformação do 'code' que o script de importação de 'code's no BD usa. Caso ele não consiga processar, busca o 'code' do jeito que ele foi passado na requisição.
Ou seja, se os códigos passados estiverem no mesmo formato que o TXT usado na importação, ele deve retornar a mesma descrição. Se estiverem no nosso formato simplificado deve funcionar também, desde que não caia no formato anterior.
Mas a questão é: esses não são os únicos formatos possíveis, certo? Por exemplo, '1000.00.00' está no formato original, que traduzimos como '1'. Ambos retornam "Receitas Correntes". Pela forma como a tradução é feita, '1000.0.0' é equivalente. Porém, '1000' não é encontrado. Deveria ser? É difícil pensar em todas as possibilidades...
Um exemplo de como está o retorno da implementação atual:
Retorna:
{ "1": "Receitas Correntes", "1.1.1.2": "Impostos sobre o Patrimônio e a Renda", "1.3.1.4": "Laudêmios", "1000": 0, "1000.0.0": "Receitas Correntes", "1000.00.00": "Receitas Correntes", "912733": 0 }
(Está retornando '0' quando não encontra. Não sei guardar 'None' em um dicionário...)
Dei uma flexibilizada na interpretação. Agora todos esses são equivalentes:
{ "1": "Receitas Correntes", "10": "Receitas Correntes", "1.0": "Receitas Correntes", "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0": "Receitas Correntes", "1000": "Receitas Correntes", "1000.00.00": "Receitas Correntes", "10000000000.000000000000.0000000000": "Receitas Correntes" }
A ideia e implementar um endpoint de acordo com o que foi feito em:
https://github.com/okfn-brasil/gastos_abertos/blob/master/gastosabertos/receita/views.py
A implementacao estara no mesmo arquivo. O endpoint devera receber apenas um argumento, o codigo da receita e o retorno devera ser a descricao da receita. O endereco do endpoint sera:
/api/v1/receita/code/CODE
E por exemplo, caso CODE seja "1.1.1" o retorno sera "Impostos". Caso seja "1.1.1.2.2" o retorno sera "IPTU - Imposto sobre a Propriedade Predial e Territorial Urbana". note que estou ignorando os zeros nao significativos dentro de um nivel, ou seja, o IPTU esta como "1112.02.00" no arquivo:
https://github.com/okfn-brasil/gastos_abertos_dados/blob/master/doc/Codificacao_de_Receitas_2013.txt