| Autor |
Mensagem |
|
|
Deveria ser o restart da aplicação. Pode tentar novamente?
Abraço
|
 |
|
|
Oi pessoal,
Na verdade a spec diz "should" o que não significa "must". Se você não implementa o should não tem problema, você é parcialmente compliant. Se você implementa *todos* os should, você é compliant. Fica semi impossivel ser totalmente compliant sem colocar um proxy no meio para analisar todas as requisicoes (o proprio servidor pode ser parcially compliant).
Mas tenho sentido que vale a pena remover a opção do created sem Location sim. O problema é compatibilidade agora, remover tem que deixar claro o motivo.
Abraço!
|
|
|
|
Tudo bem?
A versão do repositório (se aproximando da 1.0, assim que sair a 1.0 de ruby.. que tambem está proxima) é a estavel. As docs saem atualizadas junto. Enquanto isso você pode ver os exemplos dentro do proprio projeto de cliente e perguntar aqui ou na lista de discussao do VRaptor e do Restfulie por qualquer exemplo que damos uma mão.
Você estava querendo usar o client?
Abraço!
|
|
|
|
Tudo bem Israel?
Com certeza, no máximo terá uma barreira pequena por causa da linguagem, não do framework, que será mostrado durante o workshop. Minha sugestão é já estudar a sintaxe da linguagem antes que deve te ajudar bastante.
Alias, não ficou claro antes por falha minha, ex-aluno da Caelum tem 15% de desconto.
Abraço!
|
|
|
|
Tudo bem Gilmar?
Usando jsp puro você terá que pegar a variavel resultando e formata-la em html. Se voce usar alguns frameworks (veja o finalzinho do 21 com o struts 2, ou o vraptor, gwt, jsf etc) você pode usar componentes prontos que voce da o objeto e ele iterage e monta um "componente" na tela.
Agora com o primeiro passo que ja deu (de visualizar a questao request/response) o segundo passo é mostar o resultado mesmo. Voce chegou a fazer os exs da apostila tambem? Acho que eles devem ajudar a visualizar pois eles passam por exemplos de form similares.
Abraco!
|
|
|
|
Como eles se basearam em twitters para pegar a lista de palestras, o Andre havia retwitado minha mensagem sobre a palestra e eles colocaram o Andre como palestrante 
Ja deixei um recado por la.
Abraco!
|
|
|
|
joellobo wrote:
Guilherme Silveira wrote:Oi pesosoal tudo bem?
Criar um modelo que representa o que você espera é uma coisa, copiar os arquivos do remoto para o local é outra.
De qualquer maneira, o Restfulie não depende da criação de seu modelo no cliente, as docs tem alguns exemplos assim:
order = Restfulie.at(uri).get
ou ainda
Restfulie.at(uri)create {:amount =>500}.to_xml
Nenhum dos dois casos usa um modelo fixo no cliente!
Abraço!
Putz, era simplesmente isso que eu estava falando mas ainda não tinha visto que o restfulie fazia!!! Show de bola!!!
Sem mais perguntas, meritíssimo 
Sem problemas, precisando de algo, pode perguntar aqui em portugues ou na lista em ingles, como achar melhor!
|
|
|
|
mochuara wrote:
No caso do primeiro exemplo order seria um map?
Mais ou menos... é um objeto que se comporta como um map, mas mais malandro... com acesso a resposta e requisicao web etc.
Para não perder a visibilidade etc você pode registrar handlers para seu próprio media type usando o Restfulie::MediaType.register se não me engano (estou sem o codigo agora)!
É o nível de elegancia do REST que quase ninguém faz e ainda é nebuloso pra quase todo mundo, mas tá lá pra ser usado, acredito eu...
Abraço
|
|
|
|
Oi pesosoal tudo bem?
Criar um modelo que representa o que você espera é uma coisa, copiar os arquivos do remoto para o local é outra.
De qualquer maneira, o Restfulie não depende da criação de seu modelo no cliente, as docs tem alguns exemplos assim:
order = Restfulie.at(uri).get
ou ainda
Restfulie.at(uri)create {:amount =>500}.to_xml
Nenhum dos dois casos usa um modelo fixo no cliente!
Abraço!
|
|
|
|
Alex Basto wrote:
Se for pensar assim porque eu teria profissionais que em conjunto mantém e certificam normal para JSR e especificam o seu uso e pra qual compatibilidades em pro das versões Java e padrões, veja ai Java Community Press, no que você observa é puramente superficial ao conceito para a proposta de Restfulie como uma nova adquação para soluções de Hipermidia, e fiz já aqui a observação sobre a SUN CLOUD API, que já é uma evolução que não se prende ao universo somente de URI.
Eu fico impressionado
Abraco e bom finzinho de domingo!
|
|
|
|
ps: acho que ele pegou o paragrafo daqui: http://blogs.sun.com/craigmcc/entry/why_hateoas
Acho que o segundo ponto é interessante.
Abraco
|
|
|
|
Perfeito... como você disse, se os dois lados usam um protocolo conhecido o suficiente não temos problemas. Se queremos desatrelar mais o cliente do servidor, uma maneira possivel é minimizar os entry points, e o hateoas pode ajudar nisso.
Acho que é isso... se nao tem problemas com o acoplamento maior por causa dos diversos entry points.
As criticas do Roy que tentam explicar pq hypermedia faz diferenca nesses casos estao no blog do Sam Ruby:
http://intertwingly.net/blog/2008/03/23/Connecting : But hypertext as the engine of hypermedia state is also about late binding of application alternatives that guide the client through whatever it is that we are trying to provide as a service. It is fundamental to the goal of removing all coupling aside from the standardized data formats and the initial bookmark URI.
Acho que tem outros comentarios dele (e do Eric recentemente no rest-discuss) falando sobre o que voce perde com o hypermedia e eles falam melhor do que eu
Abraco!
|
|
|
|
Sinceramente, não vejo no que uma API cliente ajuda na questão da hypermedia, ou ainda, na questão da interoperabilidade que é o principal argumento do REST contra tecnologias SOA, ou seja, de que forma ter uma API amarrada entre cliente e servidor é alguma vantagem.
Ainda que a API cliente seja suportada por diferentes linguagens, me parece mais uma limitação de uma das caracteristicas da arquitetura REST (interoperabilidade), só não sei a custo de que.
Acredito que a comparação entre arquiteturas sempre deve mostrar vantagens e desvantagens. Se só estamos vendo desvantagens é pq estamos com a bala de prata nas nossas mãos - que só apresenta vantagens frente as outras soluções - que não acredito que exista.
att
|
|
|
|
Boma tarde,
Acredito que são coisas distintas. A Sun Cloud API "a RESTful API for creating and managing cloud resources" (do link que voce passou). O Restfulie é uma RESTful API... permite tanto maquina de estado quanto navegacao do cliente nos recursos do server.
Abraco
|
|
|
|
A API de cliente e como trabalhar melhor a parte de HATEOAS ficaram fora da especificação, como os proprios autores falaram:
" If I had to identify a weakness it would have to be limited support for hypermedia as the engine of state - whilst we provide good support for extracting information from request URIs and building URIs to resources, its still very much left to the developer to use hypermedia in representations appropriately."
Abraço...
|
|
|
|