Restfulie fora favorecido à Ambiente Rails para se contextualizar a assuntos de hipermidia, e na entrevista do Guilherme Silveira concedida para a InfoQ, se observa que é com conceito isolado ao padrão Restful, todavia existe o conceito Restfulie usado com Java usando o VRaptor3.
Melhor esclarecendo JSR 311: JAX-RS: The JavaTM API for RESTful Web Services, não é usado em Restfulie ou é usado de outra forma.
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
[quote=Guilherme Silveira]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[/quote]
o que ficou de fora do JAX-RS?
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…
[quote=Guilherme Silveira]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…[/quote]
“Sun Cloud API não seria o mais apropriado ao invés de usar contexto de Hipermidia na forma somente de maquina de estado”, restfulie busca cloud nesse mesma observação segue link Sun Cloud API
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
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.
[quote]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.[/quote]
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
[quote=Guilherme Silveira]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
[/quote]
Restfulie atende a observação abaixo ao seu contexto , no que se considera para Hypermedia as the Engine of Application State ele não tem outras funcionalidade a não ser o que aborda programaticamente so no universo da URI.
We started from the presumption that the service would publish only one well-known URI (returning a cloud representation containing representations for, and/or URI links to representations for, all the cloud resources that are accessible to the calling user). Every other URI in the entire system (including all those that do state changes) are discovered by examining these representations
[quote=Guilherme Silveira][quote]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.[/quote]
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[/quote]
Talvez não tenha participado de projetos REST grandes o bastante, em todos que participei, lidar com HTTP e seus cabeçalhos foi tão simples usando um framework web com suporte a url & templates e um cliente http do outro lado. Isso se deve ao fato de que o protocolo de comunicação e as representações transferidas era baseados em padrões conhecidos por ambas as partes. Mas não estou desmerecendo iniciativas como restfulie, apenas não consigo ver o que é possivel conseguir com essa integração de API cliente e servidor (ou seja, não estou vendo a vantagem) e até que ponto seria prejudicial à questão da interoperabilidade entre sistemas REST (o que seria uma desvantagem do ponto de vista de manter a arquitetura fiel ao REST, mas acho que isso pode ser o de menos sendo identificado outros benefícios na sua utilização).
[quote=Alex Basto]
We started from the presumption that the service would publish only one well-known URI (returning a cloud representation containing representations for, and/or URI links to representations for, all the cloud resources that are accessible to the calling user). Every other URI in the entire system (including all those that do state changes) are discovered by examining these representations[/quote]
Voce poderia nos dizer qual o contexto que essa citação foi retirada. Eu não lembro de ter visto qualquer referencia no assunto dizer que vc pode ter 1, e apenas 1, URI de entrada para um sistema baseado em REST.
[quote=mochuara]
Voce poderia nos dizer qual o contexto que essa citação foi retirada. Eu não lembro de ter visto qualquer referencia no assunto dizer que vc pode ter 1, e apenas 1, URI de entrada para um sistema baseado em REST.[/quote]
Eu ainda não entendi o que Restfulie esta especificando pra afirma que é uma API, sobre maquina de estado ou recursos acessados do lado do servidor isso é simplesmente um fator comum ou qualquer caracteristica REST, todavia surge uma abordagem ao VRAPTOR não provando o uso de uma especificação clara sobre o que vem só a se limitar já na obervação que você fizera acima.
Agora vamos esperar o Guilherme Silveira se colocar mais objetivamente sobre recursos da especificação Restfulie que é no minimo pra mim ainda algo ainda não materializado sendo só explorado em situação de programação sobre URI.
[quote=Alex Basto][quote=mochuara]
Voce poderia nos dizer qual o contexto que essa citação foi retirada. Eu não lembro de ter visto qualquer referencia no assunto dizer que vc pode ter 1, e apenas 1, URI de entrada para um sistema baseado em REST.[/quote]
Eu ainda não entendi o que Restfulie esta especificando pra afirma que é uma API, sobre maquina de estado ou recursos acessados do lado do servidor isso é simplesmente um fator comum ou qualquer caracteristica REST, todavia surge uma abordagem ao VRAPTOR não provando o uso de uma especificação clara sobre o que vem só a se limitar já na obervação que você fizera acima.
Agora vamos esperar o Guilherme Silveira se colocar mais objetivamente sobre recursos da especificação Restfulie que é no minimo pra mim ainda algo ainda não materializado sendo só explorado em situação de programação sobre URI.[/quote]
Marcio Duran, para de falar besteira e cite fonte da sua ultima citação. Não encontrei no link da sun cloud api.
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!
ps: acho que ele pegou o paragrafo daqui: http://blogs.sun.com/craigmcc/entry/why_hateoas
Acho que o segundo ponto é interessante.
Abraco
[quote=Alex Basto][quote=mochuara]
Voce poderia nos dizer qual o contexto que essa citação foi retirada. Eu não lembro de ter visto qualquer referencia no assunto dizer que vc pode ter 1, e apenas 1, URI de entrada para um sistema baseado em REST.[/quote]
Eu ainda não entendi o que Restfulie esta especificando pra afirma que é uma API, sobre maquina de estado ou recursos acessados do lado do servidor isso é simplesmente um fator comum ou qualquer caracteristica REST, todavia surge uma abordagem ao VRAPTOR não provando o uso de uma especificação clara sobre o que vem só a se limitar já na obervação que você fizera acima.
Agora vamos esperar o Guilherme Silveira se colocar mais objetivamente sobre recursos da especificação Restfulie que é no minimo pra mim ainda algo ainda não materializado sendo só explorado em situação de programação sobre URI.[/quote]
O que é API pra vc?
Pq o Restfulie e o VRaptor seguiriam uma especificação (JAX-RS, por exemplo) se ela não especifica a parte mais importante que eles fazem?
Se você usa REST só nas URIs e Headers, você pode usar a JAX-RS tranquilamente, pois é o suficiente… mas quando você tenta passar para o próximo nível, e começar a usar HATEOAS, o JAX-RS não te ajuda em quase nada…
API pra mim é o que atende uma especificação, não me parece ser o que Restfulie se propõe só a conceito à Maquinas de Estado ou chamadas URIs, isso é REST por si só.
[quote]
Pq o Restfulie e o VRaptor seguiriam uma especificação (JAX-RS, por exemplo) se ela não especifica a parte mais importante que eles fazem?[/quote]
Justamente Restfulie é segregado no ambiente de Rails mas não tem significativimente comportamento ou especificação de API pois não se extende a JAX-RS ou qualquer outra norma que lhe caracterize ou certifique , veja a propria entrevista do Guilherme Silveira na InfoQ Interview with Guilherme Silveira, creator of Restfulie
[quote]
Se você usa REST só nas URIs e Headers, você pode usar a JAX-RS tranquilamente, pois é o suficiente… mas quando você tenta passar para o próximo nível, e começar a usar HATEOAS, o JAX-RS não te ajuda em quase nada…[/quote]
Sim não disse o ao contrário, mas o que vem a ser Restfulie API ?
Bom, se vc procurar saber, pelo menos, o que significa a sigla (Application Programming Interface), vai ver que API nada mais é do que uma interface para programar aplicações… não tem nada ver com seguir especificações.
Por exemplo o Hibernate tem dois jeitos de fazer buscas no banco de dados: a HQL API e a Criteria API… nenhuma delas tem uma especificação da Sun 
Já vi a entrevista e de novo, ser uma API não implica seguir uma especificação ou ter um certificado, e sim disponibilizar uma Interface para realizar algum conjunto de operações.
Uma Interface para que você possa fazer aplicações usando os conceitos e funcionalidades do Restfulie.
[quote=lucascs]
Bom, se vc procurar saber, pelo menos, o que significa a sigla (Application Programming Interface), vai ver que API nada mais é do que uma interface para programar aplicações… não tem nada ver com seguir especificações.
Por exemplo o Hibernate tem dois jeitos de fazer buscas no banco de dados: a HQL API e a Criteria API… nenhuma delas tem uma especificação da Sun ;)[/quote]
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.
[quote]
Já vi a entrevista e de novo, ser uma API não implica seguir uma especificação ou ter um certificado, e sim disponibilizar uma Interface para realizar algum conjunto de operações.[/quote]
Se for para entender programação isso é atende o que você quer falar, se for falar sobre arquitetura tudo o que você colocou vai por terra abaixo.
[quote]
Uma Interface para que você possa fazer aplicações usando os conceitos e funcionalidades do Restfulie.[/quote]
Veja aqui você não consegui justificar o que é Restfulie.
Eu fico impressionado
Abraco e bom finzinho de domingo!