<div dir="ltr">Em 26 de janeiro de 2015 18:54, Renato Santos <span dir="ltr"><<a href="mailto:renato.cron@gmail.com" target="_blank">renato.cron@gmail.com</a>></span> escreveu:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">2015-01-26 18:14 GMT-02:00 Leonardo Ruoso <span dir="ltr"><<a href="mailto:leonardo@ruoso.com" target="_blank">leonardo@ruoso.com</a>></span>:<br><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Em 26 de janeiro de 2015 14:54, Renato Santos <span dir="ltr"><<a href="mailto:renato.cron@gmail.com" target="_blank">renato.cron@gmail.com</a>></span> escreveu:<br><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">Eu posso me juntar, mas já digo que eu só faço API's REST, não RESTFul,</div></blockquote></span><div><div>Rest ou Restful:</div><div><br></div><div>Se não é hyperdocument não é Rest. </div></div><div>Se tem informação out-of-band não é Rest. </div></div></div></div></blockquote><div> </div></span><div> Se informações out-of-band são informações que fazem o protocolo ser stateful, sim, é web[1], não é REST!</div></div></div></div></blockquote><div><br></div><div>Web é muito amplo, mas de uma forma geral Rest é a aplicação da Web para Software.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Quem disse que a API tem de ser Rest e não JSON-RPC ou XML-RPC?</div></div></div></div></blockquote><div><br></div></span><div>Boa pergunta, não sei... algum preconceito com o RPC, provavelmente. Mas pode estar mudando com a chegada de microservices</div></div></div></div></blockquote><div><br></div><div>O fato de que com RPC você tem obrigatoriamente forte acoplamento de client e server. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"> e que nunca ouvi falar de HyperDocument</div></blockquote><div><br></div></span><div>HyperDocument é basicamente como a WWW funciona :p</div><span><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"> e que linked-data pra mim tem que ser em RDF!</div></blockquote><div><br></div></span><div>LinkedData pode ser RDF, mas pode ser JSON-LD também.<br></div></div></div></div></blockquote></span><div>Concordo.</div><div><br>Um ponto interessante, é que, ao meu ver, para consultar as informações com SPARQL é bem devagar se comparar com os bancos tradicionais, embora tenha alguns bancos especializados neste tipo de operações.</div></div></div></div></blockquote><div><br></div><div>Mas, SPARQL como substituto de search query ou como substituto de SQL? Aí rola uma confusão comum. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>Renato, e Hateoas?<br></div></div></div></div></blockquote><div>Nunca implementei este conceito.</div></div></div></div></blockquote><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><div><div class="gmail_extra"><span><font color="#888888"><div><br></div></font></span></div></div></span></div></div></div></blockquote><div>[1] considerando que muita gente faz coisa errada com os cookies, aka, salvar informações 'out of band'</div><div><br></div><div>Nas API's que geralmente faço, apenas no 'CREATE' do recurso, que eu retorno o header Location com o URI do objecto criado.</div><div>Mas pensando bem, não seria difícil expandir os resultados para retornar a URI dos recursos em todos os lugares, ex:</div><div><font face="monospace, monospace"><br></font></div><div><div><font face="monospace, monospace">GET /books</font></div><div><font face="monospace, monospace">===</font></div><div><font face="monospace, monospace">200 OK</font></div><div><font face="monospace, monospace">content-type: application/json</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">{ rows: [ { uri: "/books/barz-mozz", name => "barz", author => { uri => "/author/mozz-2", name => "mozz" } }, { uri: "/books/2", name => "pous", ... } ], has_more: 0 }</font></div><div><font face="monospace, monospace"><br></font></div></div><div><div><font face="monospace, monospace">GET /books/barz-mozz-2</font></div><div><font face="monospace, monospace">===</font></div><div><font face="monospace, monospace">200 OK</font></div><div><font face="monospace, monospace">content-type: application/json</font></div><div><font face="monospace, monospace"><br></font></div><div><font face="monospace, monospace">{ self: { uri: "/foo/1", name => "barz" }, result_of => "/foo" }</font></div><div><br></div></div><div>=====</div></div></div></div></blockquote><div><br></div><div>Então, a questão é que também, como "engenheiros" deveríamos estar muito preocupados em adotar padrões ou recomendações, de modo que no caso de JSON deveríamos ver muito mais JSON-Schema e JSON-LD em nossos exemplos do dia-a-dia: @id, _link, _embedded e etc... já deveriam ser parte do nosso meta-vocabulário de desenvolvedores. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>não querendo fugir do assunto, mas eu estou no momento pensando muito mais em desnormalização, bancos(ideologia) "append-only" e versionamento do que no protocolo da API.</div></div></div></div></blockquote><div><br></div><div>Desnormalização como Materialização de View faz todo o sentido por motivos de performance.</div><div><br></div><div>Versionamento é uma discussão fundamental quando falamos de Rest.</div><div><br></div><div><br></div><div>Uma outra discussão importantíssima, a meu ver, é ACL e com ACL vem SSO e vem LDAP/Kerberos, Roles e Realms.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Acho que podemos começar pelo banco, até subir e chegar na camada de apresentação/input.</div></div></div></div></blockquote><div><br></div><div>Eu tenho a tendência de começar pelo banco, e poderíamos facilmente sair com um Rest Helper para Catalyst + DBIx::Class. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><span class="">-- <br><div><div><span style="color:rgb(51,51,51);font-size:x-small">Saravá,</span></div><div><span style="color:rgb(51,51,51);font-size:x-small">Renato CRON</span></div><div><div style="text-align:right"><font size="1" color="#333333"><a href="http://www.renatocron.com/blog/" target="_blank">http://www.renatocron.com/blog/</a></font></div></div><div style="text-align:right"><font size="1" color="#333333"><a href="http://twitter.com/#!/renato_cron" target="_blank">@renato_cro</a></font></div></div></span></div></div>=begin disclaimer<br>
Sao Paulo Perl Mongers: <a href="http://sao-paulo.pm.org/" target="_blank">http://sao-paulo.pm.org/</a><br>
SaoPaulo-pm mailing list: <a href="mailto:SaoPaulo-pm@pm.org">SaoPaulo-pm@pm.org</a><br>
L<<a href="http://mail.pm.org/mailman/listinfo/saopaulo-pm" target="_blank">http://mail.pm.org/mailman/listinfo/saopaulo-pm</a>><br>
=end disclaimer<br>
<br></blockquote></div><br>-- <br><div class="gmail_signature">Leonardo Ruoso<div>Journalist, Perl developer and business consultant<br><div>Media, UFC/2006; Telecom, IFCE/1998</div></div></div>
</div></div>