[Gastosabertos] API para demais esferas

[Andres MRM]

Relacionado e puxando a conversa daqui:
https://lists.okfn.org/pipermail/gastosabertos-dev/2015-March/000163.html
Ainda precisamos de um gerador de doc da API.

O que acham de usarmos o:
https://github.com/noirbizarre/flask-restplus
Ele parece casar bem com o flask-restful que já estamos usando e gera uma doc
em Swagger, que foi um formato que o Danilo comentou comigo esses dias também.



Quoting Luiz Armesto (2015-07-07 12:17:44)
> Gostei, fazer uma hierarquia "pais/estado/municipio" me parece uma boa, afinal
> não faz sentido misturar em uma mesma query esferas e locais diferentes, além
> de ser um parametro obrigatório.
> 
> dai para municipal fica, no caso de receita
> 
> /api/v1/PAIS/ESTADO/MUNICIPIO/receita/list?years=2013
> 
> Para o estadual
> 
> /api/v1/PAIS/ESTADO/receita/list?years=2013
> 
> E para o federal
> 
> /api/v1/PAIS/receita/list?years=2013
> 
> 
> 
> 
> 
> 2015-07-07 12:07 GMT-03:00 Andres MRM <andres em inventati.org>:
> 
> 
>     Tem razão. Bom, se queremos ser genéricos, cidade, estado e país me parecem
>     obrigatórios, não? Logo forte candidatos a ficar entre "barrinhas". ;)
> 
>     /brasil/sp/saopaulo/
> 
> 
>     Quoting Luiz Armesto (2015-07-07 12:02:06)
>     > Valeu pela dica, mas o questionamento é para modelagem da API e não
>     endereços
>     > de páginas. Para endereços de site eu concordo que querystring não é
>     desejável,
>     > mas no caso de API o uso ou não de querystring depende do design que
>     > decidirmos. Tem coisa que faz sentido fazer parte da querystring e outras
>     não.
>     > Parametros de filtragem faz sentido estar na querystring (e é para isso
>     que
>     > usamos), pois a maioria é opicional, alguns aceitam mais de um valor,
>     outros
>     > permitem intervalos, alguns são booleanos, etc. Mapear todos os possíveis
>     > parametros de filtragem para níveis da url torna a API muito complexa
>     tanto
>     > para implementação quanto para utilização, além de fugir do padrão
>     amplamente
>     > adotado e, portanto, diminuindo a compatibilidade com várias bibliotecas.
>     >
>     > O uso de parametros na querystring, e a decisão de quais usar, será por
>     decisão
>     > consciente e não por possivel dificuldade técnica.
>     >
>     >
>     > 2015-07-07 11:42 GMT-03:00 Andres MRM <andres em inventati.org>:
>     >
>     >
>     >     Bem pensado, Luiz.
>     >
>     >     Quoting Oda (2015-07-07 11:38:29)
>     >     > So um pitaco: me agrada o nao uso do ?var=value
>     >
>     >     Concordo com o Oda.
>     >     Também não gosto do "?a=91hhod&b=hjd982189&c=2983wo9hjd&d=9821wk928"
>     >
>     >
>     >     Quoting Oda (2015-07-07 11:38:29)
>     >     > So um pitaco: me agrada o nao uso do ?var=value
>     >     >
>     >     > Precisa amadurecer mais, mas um .htaccess com algo assim ajuda a
>     ter
>     >     > url's limpas:
>     >     >
>     >     > RewriteCond %{REQUEST_FILENAME} !-f
>     >     > RewriteCond %{REQUEST_FILENAME} !-d
>     >     > RewriteCond %{REQUEST_URI} !=/favicon.ico
>     >     > RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
>     >     >
>     >     > --
>     >     > Oda
>     >     > ------------------------------------------------------
>     >     > If you don't have time to do it right, where
>     >     > are you going to find the time to do it over?
>     >     > ------------------------------------------------------
>     >     >
>     >     >
>     >     > 2015-07-07 11:20 GMT-03:00 Luiz Armesto <luiz.armesto em gmail.com>:
>     >     > > Atualmente só estamos trabalhando com os dados do município de
>     São
>     >     Paulo,
>     >     > > mas está planejado que o projeto será ampliado para outras
>     esferas,
>     >     correto?
>     >     > >
>     >     > > Como só estamos trabalhando com dados específicos, os endpoints
>     da API
>     >     não
>     >     > > possuem identificação de onde são os dados. Por exemplo
>     >     > >
>     >     > > /api/v1/receita/list?years=2013
>     >     > >
>     >     > > lista os dados de receita para o município de São Paulo do ano de
>     2013.
>     >     Para
>     >     > > acomodar dados de receita de outras esferas, ou outros locais,
>     como
>     >     será
>     >     > > feito?
>     >     > >
>     >     > > /api/v1/receita/estadual/saopaulo/list?years=2013
>     >     > >
>     >     > > /api/v1/estadual/saopaulo/receita/list?years=2013
>     >     > >
>     >     > > /api/v1/receita/list?years=2013&estado=São%20Paulo
>     >     > >
>     >     > >
>     >     > > É bom já ter isso decidido e implementado mesmo antes de expandir
>     os
>     >     dados
>     >     > > que dispomos, para que a API se mantenha estável e não precisemos
>     >     depois
>     >     > > ficar criando novas versões e termos mais código para manter em
>     >     paralelo.
>     >     > >
>     >     > > --
>     >     > > Luiz Armesto
>     >     > >
>     >     > > _______________________________________________
>     >     > > Gastosabertos mailing list
>     >     > > Gastosabertos em lists.okfn.org
>     >     > > https://lists.okfn.org/mailman/listinfo/gastosabertos
>     >     > >
>     >     > _______________________________________________
>     >     > Gastosabertos mailing list
>     >     > Gastosabertos em lists.okfn.org
>     >     > https://lists.okfn.org/mailman/listinfo/gastosabertos
>     >     _______________________________________________
>     >     Gastosabertos mailing list
>     >     Gastosabertos em lists.okfn.org
>     >     https://lists.okfn.org/mailman/listinfo/gastosabertos
>     >
>     >
>     >
>     >
>     > --
>     > Luiz Armesto
>     _______________________________________________
>     Gastosabertos mailing list
>     Gastosabertos em lists.okfn.org
>     https://lists.okfn.org/mailman/listinfo/gastosabertos
> 
> 
> 
> 
> --
> Luiz Armesto