Em 31 de janeiro de 2015 18:09, Leonardo Ruoso <[email protected]> escreveu:
> Em 31 de janeiro de 2015 17:48, Renato Santos <[email protected]> > escreveu: > > Nem todo mundo que conheço gostam de AngularJS, algumas, inclusive, tem um >> forte ódio (quase como o Eden vs Mojolicious). >> > > Há algumas alternativas ao AngularJS. Pessoalmente eu conheço o AngularJS. > Agora, AngularJS está muito mais para Catalyst que para Mojolicious. A > tendência seria de que o Eden gostasse do AngularJS. De fato, não conheci > ninguém que eu respeite como designer de software que não respeite > considerável o AngularJS. > O AngularJS está para o Catalyst pq são dois MVCs, um trabalha no back e um no front. O Mojo pelo pouco que eu sei é um framework, http/websocket server assíncrono. Então acho que AngularJS e o Mojo trabalhariam bem juntos. Eu fiz uma implementação de AngularJS com Websocket, não usei Mojo pq o back não era Perl, mas o AngularJS tem uma biblioteca para trabalhar com o protocolo Websocket que vai tranquilo. > > >> A unica parte que não entendi até agora foi essa: >> >> - A REST API should not be dependent on any single communication >> protocol, though its successful mapping to a given protocol may be >> dependent on the availability of metadata, choice of methods, etc. In >> general, any protocol element that uses a URI for identification must >> allow >> any URI scheme to be used for the sake of that identification. *[Failure >> here implies that identification is not separated from interaction.]* >> >> Como fazer uma API comunicável por diversos protocolos? HTTP e HTTPS não >> bastam? Os outros protocolos não podem ser "tunelados" por HTTP? >> > > Se chegarmos a montar nosso grupo de estudo eu realmente gostaria de > chegar num ponte de termos ao menos um software com uma API de referência > funcionando simultaneamente em cima de HTTP(S) e AMQP (incluindo AMQP > tunelado em WebSocket). Suportando HTML, JSON e XML, mesmo que seja uma > aplicação bem simples como uma nova versão do ACT. > Já que vc considera a possibilidade de implementar algo REST-like em Websocket, segue abaixo umaa pequena tabela que mapeia diferentes características de cada protocolo. O zero é qdo não tem a característica e o um é qdo tem a característica. HTTP Websocket Stateless (Só o Client mantém estado) 1 0 Stateful (Client e Server mantém estado) 0 1 Synchronous (Blocante) 1 0 Assynchronous (Não Blocante) 0 1 HalfDuplex 1 0 FullDuplex (Real Time) 0 1 Algumas observações. 1. O Websocket é não blocante, não dá para querê-lo sincronizado. O cliente precisa trabalhar com callback, promisses, etc. 2. Para o Websocket ser assíncrono ele precisa ser stateful. 3. Para o Websocket ser RealTime, ele precisa ser stateful. Me arrisco dizer que seria complicado implementar uma API única para os dois. > > > -- > Saravá, > Renato CRON > http://www.renatocron.com/blog/ > @renato_cron <http://twitter.com/#!/renato_cron> > >> >> =begin disclaimer >> Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ >> SaoPaulo-pm mailing list: [email protected] >> 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: [email protected] > L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> > =end disclaimer > >
=begin disclaimer Sao Paulo Perl Mongers: http://sao-paulo.pm.org/ SaoPaulo-pm mailing list: [email protected] L<http://mail.pm.org/mailman/listinfo/saopaulo-pm> =end disclaimer
