| Autor |
Mensagem |
|
|
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:
|
|
|
|
Oi pessoal,
Mantendo o trabalho da Caelum em projetos open source, temos mais uma iniciativa, desta vez ligada a sistemas REST que implementam suporte a URI's, protocolo HTTP e hypermedia.
O Restfulie, originalmente em Ruby e agora em Java, força a utilização das restrições do REST.
Mais informações em
http://guilhermesilveira.wordpress.com/2009/11/25/restfulie-java-hypermedia-aware-client-client-stateless-server-quit-pretending-start-using-the-web-for-real-part-2/
http://github.com/caelum/restfulie-java
http://www.infoq.com/news/2009/12/restfulie
http://github.com/caelum/restfulie (ruby)
abraços
|
|
|
|
Tudo bem Douglas?
Infelizmente não vai dar tempo de fazer um feed live de qualidade. Disponibilizar o live apenas por uma simples camera vai deixar a transmissao com baixissima qualidade.
Mas vale lembrar que é um tutorial, onde veremos codigo e teremos um bate papo, e é isso que queremos valorizar.
Abraco
|
|
|
|
Fica a um quarteirao do metro e existem estacionamentos por causa da faculdade (quase vizinha). Como fica a um quarteirao da Caelum, tambem tem o famoso estacionamento do posto da esquina (descendo a Lins).
Abraco
|
|
|
|
A confirmacao e instantanea sim... em um futurobem proximo podemos colocar uma lista de espera se a demanda for maior do que a possivel.
Com certeza... quanto menos informacao obrigatoria, melhor.
Abraco
|
|
|
|
Guilherme, conforme for o sucesso do evento será que teremos outras versões? Gostei principalmente do networking com os criadores do projeto.
Com certeza, sendo um sucesso, continuamos com ele!
E não só com vraptor, tem tanta coisa boa que sendo um sucesso poderemos viabilizar! Vamos ver sábado que vem!
Abraço!
|
|
|
|
porque querem o CPF das pessoas para uma inscrição livre, logo vão pedir também as digitais
O sistema de eventos da caelum usa o cpf para identificar ex-alunos nos cursos, poder emitir certificados digitais para os ex-alunos e participantes etc. Todo sistema precisa de um identificador e no brasil o cpf tem sido uma ótima solução para evitar inscricoes duplicadas e fornecer as funcionalidades que comentei... mais nenhum uso.
ps: sei que é piada a questao de impressao digital mas é questao de tempo para tudo virar biometria para verificar unicidde e facilitar identificacao, nao?
|
|
|
|
o jar do spring inteiro tenta fazer alguma coisa que usa javax.naming eh javax.naming eh banido do appengine. tem que ficar sem ele mesmo. tem que ser jar picado... aqui estamos com esses no gae:
spring-beans,context,core e web. so esses 4 rola?
|
|
|
|
Repara que nao eh bem um bug. Se voce nao usa as prioridades, teoricamente nao da para saber se userMgr/login eh para fazer match com a url de baixo ou a decima.
O Lucas se referiu a implementacao de suporte a deteccao por tipo. Se user.id e' do tipo int, ele vai percebe que login nao e' int, entao nao e' para ir para essa url. Apesar de resolver alguns problemas, somente o uso de prioridade vai servir. O caso a seguir eh um exemplo que nao resolveria sem prioridade:
|
|
|
|
No momento ele so suporta classes empacotadas se voce utilizar o provider do spring. Se configurar o provider do spring voce menciona o pacote base e... pronto.
Existe uma issue para suportar isso no pico tambem.
Att
|
|
|
|