[Gastosabertos] API para demais esferas

Terça Julho 7 17:15:34 UTC 2015

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
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/gastosabertos/attachments/20150707/297c00a4/attachment-0003.html>