O DQO continua com a conversa sobre REST x WS-*.
Na argumetnação do porque-você-não-pode-simplesmente-ignorar-ws-* entram dois pontos centrais:
a) WSDL
b) REST é para HTTP apenas
Quanto a (a), eu também tinha a impressão que uma linguagem de definição de interfaces é fundamental mas mudei de idéia. Essas IDLs geralmente são muito complexas (desde CORBA) e isso está intrínseco ao fato de que devem definir tipos simples, tipos complexos, tipos do usuário, etc. de maneira auto-contida. Uma lignaugem de tipos genérica não tem como ser muito simples.
Quanto a ser editado manualmente, EJBs também foram criados apra serem editados apenas por ferramentas. Assim como eu tenho que editar EJB-Jar.XML todo santo dia eu tenho que editar WSDLs. temos um padrão aqui? Fora que os bindings SOAP para linguagens como PERL são…sofríveis. Na melhor das hipóteses. Enquanto isso qualquer coisa que faça HTTP e trate um formato como XMl está pronto para REST.
O ponto é que se eu tenho um conjunto de primitivas simples como PUT, GET, POST e DELETE eu não rpeciso de muito mais. parsers XML, YAML, JSON existem aos milhares e basta ser bem documentado para saber o que uma estrutura de dados representa.
Quanto ao ’ser HTTP-only’, sim, é uma limitação que pode não permitir o uso de REST out-of-the-box em alguns cenários. Mas SOAP, apesar de não ser dependente de transporte, não possui até onde eu sei especificações formais para o uso de JMS ou qualquer outra coisa que não seja HTTP. O que existe são implementações proprietárias destes transportes, e nada impede a criação de uma bridge JMS-HTTP, até via ESB.
Acho que o único motivo técnico real para o uso de SOAp é a abundância de ferramentas e suporte em diversos produtos. Em termos de integração, REST parece fazer muito mais sentido na maioria dos casos.