<div dir="ltr">Em 30 de janeiro de 2015 22:21, Blabos de Blebe <span dir="ltr"><<a href="mailto:blabos@gmail.com" target="_blank">blabos@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">Pera. Não entendi. Você discorda quando eu concordo com vc?<br></blockquote><div><br></div><div>Ok, deixa-me explicar, eu não concordo que seja uma questão de biscoito ou bolacha (que aliás são tão sinônimos como canjica e mungunzá ou mandioca, aipim e macaxeira). </div><div><br></div><div>A forma como você colocou deu-me a compreender que se tratava de uma discussão sobre formalismo e não sobre uma questão de cunho prático e relevante para a Ciência da Computação e Engenharia de Software.</div><div><br></div><div>Eu discordo, pois, depois de estudar Rest (eu venho do mundo de Soap/WSDL e RMI em Java), eu consigo compreender muito melhor onde está a beleza do AngularJS e como as pessoas estão fazendo muita coisa errada por aí, e isso com um impacto negativo grande na performance, na longevidade e no custo de manutenção das aplicações.</div><div><br></div><div>Existe uma razão pela qual o Rest explodiu como conceito de integração entre sistemas e essa razão não é nem cutucada por softwares que fazer JSON-RPC com forte acoplamento entre interface e API, quanto mais quando são usadas especificações AdHoc de interfaces e essa razão é redução no custo de manutenção dos softwares e longevidade dos clientes: algo ainda mais importantes quando falamos de Mobile e Internet das coisas.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">[]'s<br>
<br>
<br>
2015-01-30 19:05 GMT-02:00 Leonardo Ruoso <<a href="mailto:leonardo@ruoso.com">leonardo@ruoso.com</a>>:<br>
<div class="HOEnZb"><div class="h5">> Blabos,<br>
><br>
> Discordo profundamente e os impactos econômicos para empresas de software da<br>
> ignorância ou negligência dos profissionais são bastante significativos,<br>
> certamente não desprezíveis.<br>
><br>
> Deixo claro, no entanto, que não tenho a menor intenção de que todos<br>
> concordem, nem em usar Rest, nem em participar de um workshop sobre isso.<br>
> Acho que tem de ser algo prazeroso para pessoas que gostam de engenharia de<br>
> software ou design, que não é algo que a maioria das pessoas gosta.<br>
><br>
> Em 30 de janeiro de 2015 01:16, Blabos de Blebe <<a href="mailto:blabos@gmail.com">blabos@gmail.com</a>> escreveu:<br>
><br>
>> Nah...<br>
>><br>
>> A questão é que o termo REST, cunhado pelo tio Fielding<br>
>> (<a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm" target="_blank">http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm</a>), é bem<br>
>> específico.<br>
>><br>
>> Tecnicamente o que a gente chama de webservice REST com json pra lá e<br>
>> json pra ca não bate com a definição específica de REST criada por<br>
>> ele.<br>
>><br>
>> O próprio Fielding "dá piti" quando a gente chama nossos webservices<br>
>> de RESTful, porque não bate com o termo que ele criou.<br>
>><br>
>> O que o Leo tá dizendo é que conceitualmente existem diferenças, e a<br>
>> maioria esmagadora das pessoas, não entendem isso, gerando coisas<br>
>> bizarras, como um webservice que se comporta como SOAP, mas porque faz<br>
>> PUT e DELETE "quer ser REST".<br>
>><br>
>> No fim boa parte dessa conversa é só pra dizer se eu vou chamar o<br>
>> treco de bolacha ou de biscoito.<br>
>><br>
>> []'s<br>
>><br>
>><br>
>><br>
>> 2015-01-29 23:58 GMT-02:00 Solli Honorio <<a href="mailto:shonorio@gmail.com">shonorio@gmail.com</a>>:<br>
>> ><br>
>> ><br>
>> > Em 29 de janeiro de 2015 21:54, Kojo <<a href="mailto:rbsnkjmr@gmail.com">rbsnkjmr@gmail.com</a>> escreveu:<br>
>> >><br>
>> >> Dedo gordo, continuando.<br>
>> >><br>
>> >> Olha, realmente eu não tenho interesse em rever a documentação de SOAP<br>
>> >> e<br>
>> >> WSDL mas estou achando essas discussão interessante porque nos obriga a<br>
>> >> tratar dos diferentes padrões com rigor técnico.<br>
>> >> Não sei se vale uma palestra, mas posso contar sobre as implementações<br>
>> >> de<br>
>> >> webservice que já participei, uma delas transionando em XML, outra SOAP<br>
>> >> e<br>
>> >> outra JSON.<br>
>> >> A JSON foi bem simplesinha, a SOAP nem tanto porque trabalhar no<br>
>> >> protocolo<br>
>> >> é exaustivo, e a XML foi uma solução caseira em 2001 bem interessante.<br>
>> >> Eu<br>
>> >> teria que rever alguns documentos da época para clarear a memória, era<br>
>> >> uma<br>
>> >> coleção de interfaces em XML para diferentes tipos de dados.<br>
>> >><br>
>> >> Continuo achando que REST é para poucos porque dá para implementar um<br>
>> >> webservice de várias maneiras, mas podendo participar da discussão<br>
>> >> estou<br>
>> >> dentro.<br>
>> ><br>
>> ><br>
>> ><br>
>> > Continuo não entendendo esta afirmação de que REST só serve para poucos.<br>
>> > Neste exato momento temos bilhões de dispositivos móveis executando<br>
>> > centenas<br>
>> > de bilhões de transações de milhares de aplicativos diferentes. Se isto<br>
>> > significa que esta arquitetura é para um nicho, então não sei o que é<br>
>> > uma<br>
>> > arquitetura para a massa.<br>
>> ><br>
>> > O Leonardo fez um resumo que achei interessante, REST é WEB para<br>
>> > aplicação,<br>
>> > e é aí que vejo o poder deste cara. É tão simples que chega a ser<br>
>> > complicado, e muito leve. É muito escalável e permitir implementar a<br>
>> > tecnologia de autenticação mais adequado a tua necessidade. É muito<br>
>> > simples<br>
>> > implementar autenticação baseado em usuário/senha (inclusive com<br>
>> > kerberos)<br>
>> > via um sistema de proxy/web servicer, ou um ouath like.<br>
>> ><br>
>> > O REST é o paraíso em linguagens dinâmicas, credito até que a adoção em<br>
>> > massa na internet só ocorreu por causa do grande número de projetos<br>
>> > utilizando linguagens dinâmicas (Ruby, Python, Perl) em detrimento de<br>
>> > Java e<br>
>> > .Net (que alias é um pesadelo em utilizar o REST, mas parece que o Java<br>
>> > está<br>
>> > melhorando este quesito segundo o Leonardo).<br>
>> ><br>
>> ><br>
>> ><br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >><br>
>> >>><br>
>> >>> Em 29 de janeiro de 2015 18:49, Leonardo Ruoso <<a href="mailto:leonardo@ruoso.com">leonardo@ruoso.com</a>><br>
>> >>> escreveu:<br>
>> >>><br>
>> >>>> Há um ponto que eu considero importante: nem todos os softwares<br>
>> >>>> precisam<br>
>> >>>> ser web/rest. Muitos softwares podem usar HTTP para fazer RPC. Até aí<br>
>> >>>> nenhum<br>
>> >>>> problema.<br>
>> >>>><br>
>> >>>> O problema, a meu ver, é fazer uma coisa dizendo que está fazendo<br>
>> >>>> outra,<br>
>> >>>> pelo fato de que a outra goza de melhor reputação. Isso é, para<br>
>> >>>> começar,<br>
>> >>>> desonesto.<br>
>> >>>><br>
>> >>>> Outro ponto que vale a pena considerar é que em tudo na vida a gente<br>
>> >>>> precisa estabelecer os paradigmas sobre os quais vai trabalhar.<br>
>> >>>><br>
>> >>>> Eu toparia participar de um workshop sobre RPC com Soap/WSDL sobre<br>
>> >>>> HTTP/XMPP/SMTP, mas creio que ainda menos pessoas se interessariam<br>
>> >>>> por RPC<br>
>> >>>> já que estudar Rest parece um investimento mais promissor hoje em<br>
>> >>>> dia.<br>
>> >>>><br>
>> >>>> Pessoalmente eu estou bastante interessado em Rest, em compreender e<br>
>> >>>> talvez em entender como modelar softwares em Rest. Em especial eu<br>
>> >>>> estou<br>
>> >>>> interessado em gestão de autenticação e autorização para<br>
>> >>>> implementação de<br>
>> >>>> SSO/ACL para o que eu entendo que é fundamental para ter um software<br>
>> >>>> Rest<br>
>> >>>> que não seja equivalente à Wikipedia em termos de ACL.<br>
>> >>>><br>
>> >>>><br>
>> >>>><br>
>> >>>><br>
>> >>>><br>
>> >>>><br>
>> >>>> Em 28 de janeiro de 2015 16:34, Kojo <<a href="mailto:rbsnkjmr@gmail.com">rbsnkjmr@gmail.com</a>> escreveu:<br>
>> >>>><br>
>> >>>>> Em 28 de janeiro de 2015 11:24, Renato Santos<br>
>> >>>>> <<a href="mailto:renato.cron@gmail.com">renato.cron@gmail.com</a>><br>
>> >>>>> escreveu:<br>
>> >>>>>><br>
>> >>>>>> O protocolo HTTP em si, é stateless, e trabalha em cima do TCP.<br>
>> >>>>>><br>
>> >>>>>> O TCP sim é stateful, e existe todo um protocolo complexo (ACK,<br>
>> >>>>>> Flags,<br>
>> >>>>>> Sequence, e window size) para que todo ele funcione.<br>
>> >>>>>><br>
>> >>>>>> Como HTTP não tem estado, ou seja, a string "GET /meu-saldo\n\n"<br>
>> >>>>>> não<br>
>> >>>>>> contém nenhuma informação sobre os estados anteriores.<br>
>> >>>>>> Mesmo com headers (cookie) e query-parameters (api-key) o<br>
>> >>>>>> HTTP-per-si,<br>
>> >>>>>> é stateless.<br>
>> >>>>><br>
>> >>>>><br>
>> >>>>><br>
>> >>>>> O HTTP é stateless mas a maiorida das aplicações que rodam sobre ele<br>
>> >>>>> não, então implementam o mecanismo de sessão para manter o estado. O<br>
>> >>>>> REST<br>
>> >>>>> não, ele propõe transações atômicas para possibilitar a otimização<br>
>> >>>>> de<br>
>> >>>>> recursos, de acordo com o que vc descreve abaixo.<br>
>> >>>>><br>
>> >>>>><br>
>> >>>>>> O problema é acontece quando, como server, você precisar que algum<br>
>> >>>>>> header ou query-parameter seja enviado para algum server em<br>
>> >>>>>> especial para<br>
>> >>>>>> receber a resposta correta.<br>
>> >>>>>><br>
>> >>>>>> Os dados do Request HTTP deveriam poder passar por todos os proxys<br>
>> >>>>>> e<br>
>> >>>>>> servers sem sofrer alterações nas respostas [1].<br>
>> >>>>>><br>
>> >>>>>> Quando a aplicação recebe o HTTP e lê ele, ela deveria sempre dar<br>
>> >>>>>> uma<br>
>> >>>>>> resposta concisa sobre o que foi pedido, não importando do estado a<br>
>> >>>>>> aplicação. Ela pode ser um servidor que acabou de ligar, pode ser<br>
>> >>>>>> um que<br>
>> >>>>>> está rodando a horas, pode ser o ultimo request que o load-balance<br>
>> >>>>>> está<br>
>> >>>>>> esperando terminar antes de desligar o servidor.<br>
>> >>>>>><br>
>> >>>>>> A visão deste cookie/param tem que ser global entre os servidores.<br>
>> >>>>>> caso contrario, precisa usar sticky session. E sticky session é o<br>
>> >>>>>> que é<br>
>> >>>>>> horrível.<br>
>> >>>>>><br>
>> >>>>>> Hoje, com memcached, redis, leveldb, é muito fácil ter essa visão<br>
>> >>>>>> global dos estados de cada cliente.<br>
>> >>>>><br>
>> >>>>><br>
>> >>>>> Eu não entendo como esses mecanismos de cache impactam a arquitetura<br>
>> >>>>> stateless do REST de maneira positiva. Sei que eles trazem ganhos de<br>
>> >>>>> performance muito grande na leitura de dados, mas não que mude a<br>
>> >>>>> arquitetura<br>
>> >>>>> em sí. Vc pode dar algum exemplo?<br>
>> >>>>><br>
>> >>>>><br>
>> >>>>><br>
>> >>>>>> [1] exceção de proxys que tentam colocar cache, ad's e bloquear o<br>
>> >>>>>> acesso, mas esse nao é o proxy que eu falo!<br>
>> >>>>>> inclusive isso me lembra que, a maior parte de quem usa proxys de<br>
>> >>>>>> cache, tipo o varnish, fazem algum IF para dropar o cache caso<br>
>> >>>>>> tenha alguma<br>
>> >>>>>> indicação de 'stateful' no header/api-key.<br>
>> >>>>>><br>
>> >>>>>><br>
>> >>>>>><br>
>> >>>>>> 2015-01-28 10:45 GMT-02:00 Kojo <<a href="mailto:rbsnkjmr@gmail.com">rbsnkjmr@gmail.com</a>>:<br>
>> >>>>>><br>
>> >>>>>>>>><br>
>> >>>>>>>>> O REST mantém o conceito de HTTP stateless, ou seja, o server<br>
>> >>>>>>>>> nunca<br>
>> >>>>>>>>> sabe quem é o cliente, então não tem nada guardado em memória,<br>
>> >>>>>>>>> não tem<br>
>> >>>>>>>>> nenhuma persistência de estado dos seus dados em relação aos<br>
>> >>>>>>>>> seus clientes.<br>
>> >>>>>>>>> Isso é uma grande vantagem, mas para poucos, porque o grande<br>
>> >>>>>>>>> alívio que ele<br>
>> >>>>>>>>> trás é para os serviços web que transacionam simultaneamente com<br>
>> >>>>>>>>> milhṍes de<br>
>> >>>>>>>>> clientes, poupando memória, processamento, e infra em geral para<br>
>> >>>>>>>>> persistir<br>
>> >>>>>>>>> os dados.<br>
>> >>>>>>>><br>
>> >>>>>>>><br>
>> >>>>>>>> Não apenas, há várias outras vantagens em se trabalhar com<br>
>> >>>>>>>> stateless.<br>
>> >>>>>>><br>
>> >>>>>>><br>
>> >>>>>>> As vantagens que eu vejo no stateless estão todas relacionadas com<br>
>> >>>>>>> otimização de memória, não cache em cluster, não administração de<br>
>> >>>>>>> sessão<br>
>> >>>>>>> etc.<br>
>> >>>>>>><br>
>> >>>>>>>><br>
>> >>>>>>>><br>
>> >>>>>>>>><br>
>> >>>>>>>>> Para outros webservices, que transacionam com "poucos clientes"<br>
>> >>>>>>>>> pode ser utilizada "qualquer arquitetura" que não fará muita<br>
>> >>>>>>>>> diferença, vai<br>
>> >>>>>>>>> custar pouco e os servidores vão aguentar do mesmo jeito. Qdo<br>
>> >>>>>>>>> falo em qquer<br>
>> >>>>>>>>> arquitetura, pode até ser um "REST stateful", que na verdade não<br>
>> >>>>>>>>> é REST na<br>
>> >>>>>>>>> acepção da palavra.<br>
>> >>>>>>>><br>
>> >>>>>>>><br>
>> >>>>>>>> Qual seria um exemplo?<br>
>> >>>>>>><br>
>> >>>>>>><br>
>> >>>>>>> Por exemplo uma aplicação web stateful que ofereça todos os<br>
>> >>>>>>> métodos<br>
>> >>>>>>> que as partes necessitam em um webservice, como criação, update,<br>
>> >>>>>>> leitura e<br>
>> >>>>>>> deleção, sem se preocupar com a semântica dos métodos HTTP sem se<br>
>> >>>>>>> preocupar<br>
>> >>>>>>> em ser stateles. Em suma, uma aplicação web qquer que retorne xml,<br>
>> >>>>>>> json ou<br>
>> >>>>>>> qquer coisa inclusive documentos.<br>
>> >>>>>>><br>
>> >>>>>>>><br>
>> >>>>>>>><br>
>> >>>>>>>>><br>
>> >>>>>>>>> Em termos de penetração de mercado acho REST limitado, e<br>
>> >>>>>>>>> pensando<br>
>> >>>>>>>>> em um "REST stateful" acho que uma boa abordagem é o Websocket.<br>
>> >>>>>>>>> O Websocket<br>
>> >>>>>>>>> elimina um outro problema do HTTP que além de ser stateless, é o<br>
>> >>>>>>>>> sincronismo. O HTTP é blocante e o cliente fica pendurado<br>
>> >>>>>>>>> esperando a<br>
>> >>>>>>>>> resposta, carregando o servidor web. Já o Websocket é assincrono<br>
>> >>>>>>>>> e por isso<br>
>> >>>>>>>>> aceita milhões de requisições que não ficam penduradas.<br>
>> >>>>>>>><br>
>> >>>>>>>><br>
>> >>>>>>>> WebSocket funciona em cima de HTTP :p<br>
>> >>>>>>><br>
>> >>>>>>><br>
>> >>>>>>> Funciona sobre HTTP mas não é uma premissa. O Websocket usa o HTTP<br>
>> >>>>>>> para fazer handshake e aproveita toda a infra do HTTP como as<br>
>> >>>>>>> portas 80 e<br>
>> >>>>>>> 443, proxy etc, mas a idéia é futuramente mandar ele para outra<br>
>> >>>>>>> porta e<br>
>> >>>>>>> deixar o protocolo independente. Ele funciona como se fosse<br>
>> >>>>>>> tunelado, ou<br>
>> >>>>>>> seja, se vc estabelecer uma camada de transporte para ele, o resto<br>
>> >>>>>>> já tá<br>
>> >>>>>>> pronto. E a RFC diz que futuramente vai ser feito.<br>
>> >>>>>>><br>
>> >>>>>>><br>
>> >>>>>>><br>
>> >>>>>>>><br>
>> >>>>>>>> WebSocket per-se provavelmente é uma má-ideia. Provavelmente AMQP<br>
>> >>>>>>>> sobre WebSocket seja uma solução mais robusta.<br>
>> >>>>>>>><br>
>> >>>>>>>> E em muito tempo a única forma racional (efetiva, eficaz e<br>
>> >>>>>>>> eficiente) que encontrei para implementar sistemas com WebSocket<br>
>> >>>>>>>> é baseada<br>
>> >>>>>>>> em Schema/LD.<br>
>> >>>>>>><br>
>> >>>>>>><br>
>> >>>>>>> Faz sentido, pq o Websocket é um protocolo e REST é uma<br>
>> >>>>>>> arquitetura.<br>
>> >>>>>>> AMQP começa a ser uma composição de MQ com Websocket e tal. Aí<br>
>> >>>>>>> começa a se<br>
>> >>>>>>> montar uma arquitetura compondo várias tecnologias e protocolos.<br>
>> >>>>>>><br>
>> >>>>>>><br>
>> >>>>>>>>><br>
>> >>>>>>>>> Não estou dizendo que a arquitetura REST não é boa nem que não<br>
>> >>>>>>>>> tem<br>
>> >>>>>>>>> utilidade, mas que é para poucos. HATEOAS me soa a mesma coisa,<br>
>> >>>>>>>>> eu nunca<br>
>> >>>>>>>>> tinha ouvido falar, mas me lembrou WSDL, SOAP, etc.<br>
>> >>>>>>>><br>
>> >>>>>>>><br>
>> >>>>>>>> Na verdade Rest é oposto a SOAP, que embora também suporte<br>
>> >>>>>>>> documentos e não apenas RPC, não tem as premissas de funcionar em<br>
>> >>>>>>>> WEB.<br>
>> >>>>>>>><br>
>> >>>>>>>> Mas, sim, para fazer RPC tunelado sobre HTTP, XMPP, SMTP eu diria<br>
>> >>>>>>>> que ainda hoje o padrão mais maduro é, sem dúvida, SOAP/WSDL.<br>
>> >>>>>>>> Certamente é o<br>
>> >>>>>>>> que torna o desenvolvimento de software mais fácil.<br>
>> >>>>>>><br>
>> >>>>>>><br>
>> >>>>>>> Eu já trabalhei em uma implementação de SOAP e WSDL em PERL. A<br>
>> >>>>>>> empresa consumia os nossos webservices e foi uma solução<br>
>> >>>>>>> interessante, a<br>
>> >>>>>>> arquitetura era deles. Eu acho que a solução funcionava bem porque<br>
>> >>>>>>> não eram<br>
>> >>>>>>> muitos requests, senão valeria a pena pensar em algo assíncrono.<br>
>> >>>>>>><br>
>> >>>>>>><br>
>> >>>>>>><br>
>> >>>>>>><br>
>> >>>>>>><br>
>> >>>>>>>><br>
>> >>>>>>>><br>
>> >>>>>>>>><br>
>> >>>>>>>>><br>
>> >>>>>>>>> Em 26 de janeiro de 2015 21:08, Leonardo Ruoso<br>
>> >>>>>>>>> <<a href="mailto:leonardo@ruoso.com">leonardo@ruoso.com</a>><br>
>> >>>>>>>>> escreveu:<br>
>> >>>>>>>>><br>
>> >>>>>>>>>><br>
>> >>>>>>>>>> Em 26 de janeiro de 2015 18:20, Lucas Mateus<br>
>> >>>>>>>>>> <<a href="mailto:lucasmateus.oliveira@gmail.com">lucasmateus.oliveira@gmail.com</a>> escreveu:<br>
>> >>>>>>>>>>><br>
>> >>>>>>>>>>><br>
>> >>>>>>>>>>> Eu uso o Catalyst::Controller::REST que implementa todo o<br>
>> >>>>>>>>>>> “sexo<br>
>> >>>>>>>>>>> dos anjos” pra mim e vou ser feliz :D<br>
>> >>>>>>>>>><br>
>> >>>>>>>>>><br>
>> >>>>>>>>>> Não falta pretenção para o Catalyst::Controller::REST<br>
>> >>>>>>>>>><br>
>> >>>>>>>>>> Quanto a ser feliz, bem, eu acredito que se conseguirmos<br>
>> >>>>>>>>>> construir<br>
>> >>>>>>>>>> uma infraestrutura de software e uma prova de conceito Rest em<br>
>> >>>>>>>>>> Perl, em cima<br>
>> >>>>>>>>>> do Catalyst, por exemplo, com View, Controller e Model<br>
>> >>>>>>>>>> requerendo interfaces<br>
>> >>>>>>>>>> Rest de classes Moose (incluindo DBIx::Class Result(set)),<br>
>> >>>>>>>>>> vamos ser mais<br>
>> >>>>>>>>>> que felizes.<br>
>> >>>>>>>>>><br>
>> >>>>>>>>>> Se tiver uma galera na comunidade Perl entendo o que é Rest eu<br>
>> >>>>>>>>>> já,<br>
>> >>>>>>>>>> pessoalmente, ficarei muito feliz demais da conta.<br>
>> >>>>>>>>>><br>
>> >>>>>>>>>> Que a galera Java, por exemplo, já está acordando para a vida.<br>
>> >>>>>>>>>><br>
>> >>>>>>>>>>> Em 26/01/2015, à(s) 18:18, Leonardo Ruoso <<a href="mailto:leonardo@ruoso.com">leonardo@ruoso.com</a>><br>
>> >>>>>>>>>>> escreveu:<br>
>> >>>>>>>>>>><br>
>> >>>>>>>>>>> Em todo caso, mesmo que seja possível fazer (JSON|XML)-RPC bem<br>
>> >>>>>>>>>>> feito, há um motivo pelo qual todo mundo quer Rest: REST É O<br>
>> >>>>>>>>>>> ÚLTIMO BISCOITO<br>
>> >>>>>>>>>>> DO PACOTE! JSON-RPC funciona, mas não é Rest e por isso não<br>
>> >>>>>>>>>>> tem todas as<br>
>> >>>>>>>>>>> vantagens sensacionais do Rest.<br>
>> >>>>>>>>>>><br>
>> >>>>>>>>>>> Em 26 de janeiro de 2015 14:54, Renato Santos<br>
>> >>>>>>>>>>> <<a href="mailto:renato.cron@gmail.com">renato.cron@gmail.com</a>> escreveu:<br>
>> >>>>>>>>>>>><br>
>> >>>>>>>>>>>> Eu posso me juntar, mas já digo que eu só faço API's REST,<br>
>> >>>>>>>>>>>> não<br>
>> >>>>>>>>>>>> RESTFul, e que nunca ouvi falar de HyperDocument e que<br>
>> >>>>>>>>>>>> linked-data pra mim<br>
>> >>>>>>>>>>>> tem que ser em RDF!<br>
>> >>>>>>>>>>>><br>
>> >>>>>>>>>>>><br>
>> >>>>>>>>>>>><br>
>> >>>>>>>>>>>> 2015-01-26 14:51 GMT-02:00 Lucas Mateus<br>
>> >>>>>>>>>>>> <<a href="mailto:lucasmateus.oliveira@gmail.com">lucasmateus.oliveira@gmail.com</a>>:<br>
>> >>>>>>>>>>>>><br>
>> >>>>>>>>>>>>><br>
>> >>>>>>>>>>>>> Em 25/01/2015, à(s) 18:45, Leonardo Ruoso<br>
>> >>>>>>>>>>>>> <<a href="mailto:leonardo@ruoso.com">leonardo@ruoso.com</a>><br>
>> >>>>>>>>>>>>> escreveu:<br>
>> >>>>>>>>>>>>><br>
>> >>>>>>>>>>>>> Caso na comunidade tenha gente disposta a se atualizar sobre<br>
>> >>>>>>>>>>>>> Restful (um conceito novo, lançado em 2000, e que se tornou<br>
>> >>>>>>>>>>>>> a principal<br>
>> >>>>>>>>>>>>> vedete do desenvolvimento de software contemporâneo) e<br>
>> >>>>>>>>>>>>> disposta a parar de<br>
>> >>>>>>>>>>>>> mentir para seus chefes e clientes de que está entregando<br>
>> >>>>>>>>>>>>> restful quando<br>
>> >>>>>>>>>>>>> está na verdade entregando um tipo de RPC mais-que-porco, eu<br>
>> >>>>>>>>>>>>> teria um imenso<br>
>> >>>>>>>>>>>>> prazer em integrar um grupo de estudo e de desenvolvimento<br>
>> >>>>>>>>>>>>> com esse<br>
>> >>>>>>>>>>>>> objetivo.<br>
>> >>>>>>>>>>>>><br>
>> >>>>>>>>>>>>><br>
>> >>>>>>>>>>>>> Hahaha comunidade de mentirosos :D<br>
>> >>>>>>>>>>>>><br>
>> >>>>>>>>>>>>> =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>
>> >>>>>>>>>>>><br>
>> >>>>>>>>>>>><br>
>> >>>>>>>>>>>><br>
>> >>>>>>>>>>>> --<br>
>> >>>>>>>>>>>> Saravá,<br>
>> >>>>>>>>>>>> Renato CRON<br>
>> >>>>>>>>>>>> <a href="http://www.renatocron.com/blog/" target="_blank">http://www.renatocron.com/blog/</a><br>
>> >>>>>>>>>>>> @renato_cron<br>
>> >>>>>>>>>>>><br>
>> >>>>>>>>>>>> =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>
>> >>>>>>>>>>><br>
>> >>>>>>>>>>><br>
>> >>>>>>>>>>><br>
>> >>>>>>>>>>> --<br>
>> >>>>>>>>>>> Leonardo Ruoso<br>
>> >>>>>>>>>>> Journalist, Perl developer and business consultant<br>
>> >>>>>>>>>>> Media, UFC/2006; Telecom, IFCE/1998<br>
>> >>>>>>>>>>> =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>
>> >>>>>>>>>>><br>
>> >>>>>>>>>>><br>
>> >>>>>>>>>>> =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>
>> >>>>>>>>>><br>
>> >>>>>>>>>><br>
>> >>>>>>>>>><br>
>> >>>>>>>>>> --<br>
>> >>>>>>>>>> Leonardo Ruoso<br>
>> >>>>>>>>>> Journalist, Perl developer and business consultant<br>
>> >>>>>>>>>> Media, UFC/2006; Telecom, IFCE/1998<br>
>> >>>>>>>>>><br>
>> >>>>>>>>>> =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>
>> >>>>>>>>><br>
>> >>>>>>>>><br>
>> >>>>>>>>> =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>
>> >>>>>>>><br>
>> >>>>>>>><br>
>> >>>>>>>><br>
>> >>>>>>>> --<br>
>> >>>>>>>> Leonardo Ruoso<br>
>> >>>>>>>> Journalist, Perl developer and business consultant<br>
>> >>>>>>>> Media, UFC/2006; Telecom, IFCE/1998<br>
>> >>>>>>>><br>
>> >>>>>>>> =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>
>> >>>>>>><br>
>> >>>>>>><br>
>> >>>>>>> =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>
>> >>>>>><br>
>> >>>>>><br>
>> >>>>>><br>
>> >>>>>> --<br>
>> >>>>>> Saravá,<br>
>> >>>>>> Renato CRON<br>
>> >>>>>> <a href="http://www.renatocron.com/blog/" target="_blank">http://www.renatocron.com/blog/</a><br>
>> >>>>>> @renato_cron<br>
>> >>>>>><br>
>> >>>>>> =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>
>> >>>>><br>
>> >>>>><br>
>> >>>>> =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>
>> >>>><br>
>> >>>><br>
>> >>>><br>
>> >>>> --<br>
>> >>>> Leonardo Ruoso<br>
>> >>>> Journalist, Perl developer and business consultant<br>
>> >>>> Media, UFC/2006; Telecom, IFCE/1998<br>
>> >>>><br>
>> >>>> =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>
>> >>><br>
>> >><br>
>> >><br>
>> >> =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>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > "o animal satisfeito dorme". - Guimarães Rosa<br>
>> ><br>
>> > =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>
>> =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>
><br>
><br>
><br>
> --<br>
> Leonardo Ruoso<br>
> Journalist, Perl developer and business consultant<br>
> Media, UFC/2006; Telecom, IFCE/1998<br>
><br>
> =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>
=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>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <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>