Em 26 de janeiro de 2015 18:54, Renato Santos <renato.c...@gmail.com> escreveu:
> 2015-01-26 18:14 GMT-02:00 Leonardo Ruoso <leona...@ruoso.com>: > >> Em 26 de janeiro de 2015 14:54, Renato Santos <renato.c...@gmail.com> >> escreveu: >> >>> Eu posso me juntar, mas já digo que eu só faço API's REST, não RESTFul, >>> >> Rest ou Restful: >> >> Se não é hyperdocument não é Rest. >> Se tem informação out-of-band não é Rest. >> > > Se informações out-of-band são informações que fazem o protocolo > ser stateful, sim, é web[1], não é REST! > Web é muito amplo, mas de uma forma geral Rest é a aplicação da Web para Software. > Quem disse que a API tem de ser Rest e não JSON-RPC ou XML-RPC? >> > > Boa pergunta, não sei... algum preconceito com o RPC, provavelmente. Mas > pode estar mudando com a chegada de microservices > O fato de que com RPC você tem obrigatoriamente forte acoplamento de client e server. > e que nunca ouvi falar de HyperDocument >>> >> >> HyperDocument é basicamente como a WWW funciona :p >> >> >>> e que linked-data pra mim tem que ser em RDF! >>> >> >> LinkedData pode ser RDF, mas pode ser JSON-LD também. >> > Concordo. > > 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. > Mas, SPARQL como substituto de search query ou como substituto de SQL? Aí rola uma confusão comum. > Renato, e Hateoas? >> > Nunca implementei este conceito. > > >> [1] considerando que muita gente faz coisa errada com os cookies, aka, > salvar informações 'out of band' > > Nas API's que geralmente faço, apenas no 'CREATE' do recurso, que eu > retorno o header Location com o URI do objecto criado. > Mas pensando bem, não seria difícil expandir os resultados para retornar a > URI dos recursos em todos os lugares, ex: > > GET /books > === > 200 OK > content-type: application/json > > { rows: [ { uri: "/books/barz-mozz", name => "barz", author => { uri => > "/author/mozz-2", name => "mozz" } }, { uri: "/books/2", name => "pous", > ... } ], has_more: 0 } > > GET /books/barz-mozz-2 > === > 200 OK > content-type: application/json > > { self: { uri: "/foo/1", name => "barz" }, result_of => "/foo" } > > ===== > 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. > 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. > Desnormalização como Materialização de View faz todo o sentido por motivos de performance. Versionamento é uma discussão fundamental quando falamos de Rest. Uma outra discussão importantíssima, a meu ver, é ACL e com ACL vem SSO e vem LDAP/Kerberos, Roles e Realms. > Acho que podemos começar pelo banco, até subir e chegar na camada de > apresentação/input. > Eu tenho a tendência de começar pelo banco, e poderíamos facilmente sair com um Rest Helper para Catalyst + DBIx::Class. -- > Saravá, > Renato CRON > http://www.renatocron.com/blog/ > @renato_cro <http://twitter.com/#!/renato_cron> > =begin disclaimer > Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ > SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > =end disclaimer > > -- Leonardo Ruoso Journalist, Perl developer and business consultant Media, UFC/2006; Telecom, IFCE/1998
=begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: SaoPaulo-pm@pm.org L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer