[Gastosabertos] API para demais esferas

Terça Julho 7 15:02:06 UTC 2015

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