Muito bons seus comentários, aprendi um bocado, de fato o servico pode ser query/atributo1/atributo2/from/{entidade} no caso /o * é para deixar proxima do contexto de linguagem de SQLs, JPA-QL e afins.

A minha Java Magazine chegou hj no meu apto, eu nao tive tempo de ler ainda pq tive q viajar hj de noite, estou em Goiania , mas assim que eu voltar vou dar uma lida com certeza.

Abracos
Edgar

A única “ressalva” quanto a isso é que se implementarmos um protocolo de comunicação que fuja muito das principais boas práticas, os clientes que precisarem consumir os serviços terão um pouco mais de dificuldade para conhecer o seu protocolo.

Sobre o seu serviço, de fato eu me enganei. Eu não tinha visto o serviço como uma query, mas como uma URI de acesso ao recurso “vertical”. Se o serviço é Query, realmente ficou bem mais adequado do que eu havia comentado.

Só uma pequena observação: eu acho o “*” um pouco redundante na URI /rest/query/*/from/verticais. Eu acho que fica melhor você colocar /rest/query/from/verticais a não ser que você tenha planos de usar esta estrutura para pegar atributos individuais. Se você pretende ter uma URI /rest/query/*/from/verticais e outra URI /rest/query/id/from/verticais, aí faz sentido manter o *. Caso contrário acho mais legal tirá-lo.

Sobre a implementação, a maioria dos serviços REST que eu implementei foram com Servlets simples e com o XStream mesmo. Entretanto, para implementar uma aplicação com vários serviços, e recursos ricos, acho melhor usar o Jersey.

Uma bela dica que deixo é que você dê uma olhada na RFC do Atom Publishing Protocol, a RFC 5023. O AtomPub pode ser visto como um blueprint de serviços REST, e muita gente o toma como referência para modelar o protocolo de comunicação dos serviços. É uma ótima leitura.

Grande abraço,

Bruno Pereira

Obrigado pelos comentários, sempre são bem vindos. Seu comentário na verdade só enriqueceu o post.

Algumas questoes apenas: Um entendimento que eu tive a respeito de REST é que elementos facilitadores devem ser aplicados, onde o protocolo pode ser flexivel, ao passo que acredito que servicos como os do FaceBook, Flickr, del.ic.ous,Ning etc , podem ser desenhados no padrão que cabe a cada um deles, do contrário REST seria tão burocrático quanto seu irmao mais velho WS.

Quando a interpretação do meu servico, será que voce imaginou que o servico na verdade é Query, e que as minhas RegExp se tornam na verdade um pequeno analisador similar ao de um SQL? Será que ainda assim, ficaria errado?

Para me ambasar melhor, li a seção 3.6.2 Request Matching, da Spec JSR311, onde vi:
1. Identify the root resource class:
(a) Set U = request URI path,C = {root resource classes},E = {}
(b) For each class in C add a regular expression (computed using the function R(A) described in 31
section 3.6.3) to E as follows: 32
• Add R(Tclass) where Tclass is the URI path template specified for the class.

Partindo desses padrões, acredito que possa modelar um pouco mais próximo da Spec as urls dos meus servicos, do contrário fica tão pessoal quanto alguns desenhos de processos em BPM.

Eu nao usei nenhum framework, e sim um bom e velho Servlet, uma coisa interessante é q fiz alguns testes com Interceptors para “simular” meus eventos dentro do barramento ESB.

Na minha humilde opinião, esta URI que você falou não é RESTful. De uma maneira geral, a URI dos serviços deve indicar O QUE (QUAL recurso) você está manipulando, e o método (ou verbo) HTTP deve indicar COMO você está manipulando.

Neste seu exemplo, se o seu recurso é uma “vertical”, eu colocaria a URI como /vertical. A URI /vertical/{id} indicaria uma vertical específica. A URI /vertical sem especificar o ID indicaria a coleção inteira de verticais.

O formato da URI que você colocou é mais no formato fazerEssaOperacao, estilo WS-*. Eu sugiro tentar sempre moldar as URIs no sentido de deixar claro QUAL é o recurso, ou possivelmente associações entre recursos.

Por exemplo, eu nem sei o que representa “vertical” na sua aplicação, mas supondo que você tenha o recurso “vertical” e outro chamado “horizontal”, uma URI que represente a relação entre uma determinada “vertical” e uma determinada “horizontal” poderia ser: /vertical/123/horizontal/456, onde 123 e 456 são os respectivos IDs.

Eu escrevi o artigo da capa da Java Magazine desse mês, sobre serviços REST. Talvez você ache interessante

Ah, e algo que eu recomendo é começar com Servlets e XStream mesmo. Quando você já tiver identificado pontos onde gostaria de melhorar, dá uma olhada na JSR-311 e no Jersey, a implementação de referência da JSR. O Jersey é muito interessante, e resolve problemas como o mapeamento de URIs em Classes e métodos, e faz os bindings XML para você. Na verdade ele faz bem mais que isso, mas depois você dá uma olhada.

Parabéns pelo blog.

Grande abraço,

Bruno Pereira