[Gastosabertos] API para demais esferas

Andres MRM andres em inventati.org
Segunda Julho 13 02:03:25 UTC 2015


Experimentei a Restplus para o primeiro endpoint da execução.
Já está gerando a doc swagger:
http://demo.gastosabertos.org/
=P


Quoting Danilo Oliveira (2015-07-07 14:15:34)
> Pessoal,
> Eu tenho usado o Swagger e a minha impressão q é um ótimo meio de documentar e
> disponibilizar as APIS.
> Neste repositório vocês encontram várias ferramentas que auxiliam o uso do
> Swagger!
> 
> https://github.com/swagger-api
> 
> 
> 2015-07-07 13:11 GMT-03:00 Luiz Armesto <luiz.armesto em gmail.com>:
> 
>     Dei só uma olhada por cima, depois vejo com mais calma, mas acho que vale a
>     pena experimentar. Parece que não precisa mudar praticamente nada do que
>     está feito.
> 
>     2015-07-07 12:45 GMT-03:00 Andres MRM <andres em inventati.org>:
> 
> 
>         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
>         _______________________________________________
>         Gastosabertos mailing list
>         Gastosabertos em lists.okfn.org
>         https://lists.okfn.org/mailman/listinfo/gastosabertos
> 
> 
> 
> 
>     --
>     Luiz Armesto
> 
> 
> 
> 
> --
> Danilo Amaral de Oliveira
> Engenheiro de Computação
> whats (11) 95282-3504



Mais detalhes sobre a lista de discussão Gastosabertos