[SP-pm] Resumo do Evento Técnico

Leonardo Ruoso leonardo at ruoso.com
Mon Jan 26 15:03:56 PST 2015


Em 26 de janeiro de 2015 18:54, Renato Santos <renato.cron em gmail.com>
escreveu:

> 2015-01-26 18:14 GMT-02:00 Leonardo Ruoso <leonardo em ruoso.com>:
>
>> Em 26 de janeiro de 2015 14:54, Renato Santos <renato.cron em 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 em 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
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20150126/32697bb4/attachment-0001.html>


More information about the SaoPaulo-pm mailing list