Guilherme Silveira wrote: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

Guilherme Silveira wrote: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...

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.

Guilherme Silveira wrote: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

Guilherme Silveira wrote:

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

Alex Basto wrote:
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

mochuara wrote:

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.

Alex Basto wrote:

mochuara wrote:

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.

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.