WebServices é uma grande tecnologia, mas lembro que quado trabalhei num grande projeto da Caixa, a missão era transacionar dados via um Servlet e um XML que o biding era feito via JAXB. Isso, fazem quase 4 anos, nesse tempo o XStream ficou muito mais famoso, e mais performático, enquanto SOAP, vem melhorando, ganhando força em padronizações e enriquecendo em termos de complexidade. Eis que surge o REST, que traz uma forma bem mais simples como resposta para integração de sistemas que envolvam XML ou até mesmo outros formatos de metadados.
Numa nova demo-from-the-hell, pro JBoss ESB, fiz uma implementação de um servico em REST, usando simples Servlets e haja expressões regulares, para criar um serviço simples, mas também aproveitei para estudar o framework “REstLet”.
No REst a liberdade impera, sendo assim, defini que meu protocolo seria:
http://meuservico:8080/rest/query/*/from/verticais
Com base nesta URL, minha linguagem de protocolo diz: Consulte todos de verticais , pronto isto é suficiente para definir meu serviço. Como Java agora está ser tornando uma droga de CLR(common language run-time) como a do .net, meu cliente mais uma vez usa uma linguagem trivial: O ObjectPascal, ou DelphiLanguage. Não que eu seja ainda alguém que ainda lembre de vários detalhes do Delphi, mas o cliente funcionou muito bem, utilizando os componentes Indy Components.
Trazendo para o mundo do ESB, estou na fase de como ativar eventos e notificações quando o Rest é chamado, isto eu já vi que é possível, com o RestLET. As pesquisas continuam. Em próximas apresentações por algum evento ai a fora, essa demo será uma das que devem ser apresentadas.
[]s
Entries (RSS)
April 11th, 2008 at 11:43 am
Oi Edgar, tudo bem?
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
April 13th, 2008 at 5:10 am
Olá Bruno,
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.
April 13th, 2008 at 12:30 pm
Oi Edgar, realmente temos total liberdade para moldar o protocolo de comunicação REST de acordo com as nossas preferências. Isto é muito bom e traz bastante liberdade.
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
April 14th, 2008 at 3:20 am
Oi Bruno,
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