| Autor |
Mensagem |
|
|
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...
|
|
|
|
Tudo bom Alex? Acho que voce se baseou na pergunta do Marcio, certo?
Voce esta certo, JAX-RS não é usado no Restfulie: ele não segue a API do Java EE pois tenta adicionar conceitos do REST que acabaram ficando de fora do JAX-RS.
Att
|
|
|
|
O controle de transacao dentro de uma requisicao realmente é interno e nao depende do Restfulie.
A vantagem do restfulie entra na parte do hypermedia... se nao for necessario ele, so o representation deve ser suficiente!
Abraco
|
|
|
|
Bom dia Davi, Garcia,
Realmente a exception parece não estar usando o XStream com a configuração que voce citou. Mas como no cliente não poderá usar o restfulie por ser celular, deixamos de lado. Se aparecer o problema novamente, poste o código do cliente por aqui?
Sobre SOAP consumir REST, como as mensagens em REST geradas pelo serializador não está envelopada em soap por padrão, não funcionará.
Mas a questão da arquitetura REST não possuir um contrato formal é um pouco diferente. Você pode - e muitos dizem que deve - criar xsd's ou utilizar o schematron para fazer a validação de sua estrutura xml e REST não te proibe de faze-lo, basta adicionar o cabeçalho com link para seu schema:
Tem um post aqui sobre o assuntO: http://guilhermesilveira.wordpress.com/2009/12/08/hypermedia-making-it-easier-to-create-dynamic-contracts/
O REST também possui as informações (metadados) que o soap define em diversos momentos, mas utiliza cabeçalhos http (o protocolo em si) para passar parte dessas informações.
Na parte de criar uma classe anotada/não anotada para ser usada nos dois lugares, algumas pessoas vão recomendar não usar a mesma classe mesmo: se você disponibiliza a mesma classe para os dois lados, você aumenta o acoplamento entre os dois lados. Permitindo cada lado ter uma representação diferente (com os campos que interessa para cada um) diminui o acoplamento, mas isso só faz sentido se você for disponibilizar para outros clientes diferentes.
Abraço
|
|
|
|
|
Otimo! Mais sugestoes pode mandar! Obrigado.
|
|
|
|
Concordo plenamente! Alguns momentos vai haver o mapeamento 1x1 e em outros momentos não.
Por isso que o Restfulie não assume esse mapeamento entre 1:1 entre resources e objetos: você serializa ou devolve o seu recurso: de onde ele veio, não importa.
Infelizmente não acho que tenha solução diferente do que você mencionou mesmo:
Dados N elementos em um espaco de origem e 1 elemento no espaço destino, se voce deseja transformar um em outro, precisa de uma função de transformacao... seguindo um padrão ou parametrizado.
No restfulie você pode fazer exatamente o que você comentou (criar o resource customizado independente do objeto original):
|
|
|
|
Tudo bom?
Não sei se peguei direito o problema. Você pode fazer:
|
|
|
|