Serviços RESTful - Equivalente WSDL

Tenho lido sobre REST e SOAP e entendo por que implementar REST pode ser benéfico em relação ao uso de um protocolo SOAP. No entanto, ainda não entendo por que não existe o equivalente "WSDL" no mundo REST. Já vi posts dizendo que "não há necessidade" do WSDL ou que seria redundante no mundo REST, mas não entendo por quê. Não é sempre útil vincular programaticamente a uma definição e criar classes de proxy em vez de codificar manualmente? Não quero entrar em um debate filosófico, apenas procurando a razão pela qual não há WSDL no REST, ou por que não é necessário. Obrigado.

A Web Application Description Language (WADL) é basicamente o equivalente a WSDL para serviços RESTful, mas há uma controvérsia em andamento se algo como isso é necessário.

Joe Gregorio escreveu um bom artigo sobre esse assunto que vale a pena ler.

WSDL descreve terminais de serviço. Os clientes REST não devem ser acoplados aos terminais do servidor (ou seja, não devem estar cientes dos URLs com antecedência). Os clientes REST são acoplados aos tipos de mídia que são transferidos entre o cliente e o servidor.

Pode fazer sentido gerar classes automaticamente no cliente para envolver os tipos de mídia retornados. No entanto, assim que você começa a criar classes de proxy em torno das interações de serviço, você começa a obscurecer as interações HTTP e corre o risco de degenerar de volta para um modelo RPC.

RSDL tem como objetivo tornar o resto uma hipermídia, ou seja, possui mais informações do que um descritor de serviço como WSDL ou WADL. Por exemplo, ele contém as informações sobre navegação, como hipertexto e hiperlinks.

Por exemplo, dado um recurso atual, você tem um conjunto de links para outros recursos relacionados.

No entanto, não encontrei Rest Clients que suportem este formato ou Rest Server Solutions com um recurso de geração automática.

Acho que há um longo caminho para uma conclusão sobre isso. Veja a longa história do HTML e W3C vs Browsers lol.

Para mais detalhes sobre Rest like Hypermedia veja: http://en.wikipedia.org/wiki/HATEOAS

Nota: Roy Fielding tem criticado essas tendências em Rest Apis sem a abordagem de hipermídia: http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Minha Conclusão: Hoje em dia, WADL é mais comum que Rest e Frameworks de Integração como Camel CXF já suportam WADL (gerar e consumir), porque é semelhante a WSDL, portanto mais fácil de entender neste processo de migração (SOAP para REST).

Vamos ver os próximos capítulos;)

Não é sempre útil vincular programaticamente a uma definição e criar classes de proxy em vez de codificar manualmente?

Concordo plenamente, é por isso que uso Swagger.io

Swagger é uma poderosa estrutura de software livre apoiada por um grande ecossistema de ferramentas que ajuda a projetar, construir, documentar e consumir suas APIs RESTful.

Então, basicamente, eu uso o Swagger para descrever meus modelos, terminais, etc, e então uso outras ferramentas como swagger-codegen para gerar as classes de proxy em vez de codificá-las manualmente.

Veja também: RAML

Há uma RSDL (linguagem de descrição de serviço repousante) que é equivalente a WSDL. O URL abaixo descreve sua prática http://en.wikipedia.org/wiki/HATEOAS e http://en.wikipedia.org/wiki/RSDL . O problema é que temos muitas ferramentas para gerar código de wsdl para java ou reverso. Mas não encontrei nenhuma ferramenta para gerar código a partir do RSDL.

WSDL é extensível para permitir a descrição de terminais e suas mensagens, independentemente de quais formatos de mensagem ou protocolos de rede são usados ​​para se comunicar

No entanto, REST usa o protocolo de rede usando verbos HTTP e o URI para representar o estado de um objeto.

WSDLs informam neste local, se você enviar esta mensagem, você executará esta ação e obterá este formato de volta como resultado.

No REST, se eu quisesse criar um novo perfil, usaria o verbo POSTcom um corpo JSON ou variáveis ​​de servidor http descrevendo meu perfil para a URL/profile

POSTdeve retornar um ID gerado pelo servidor, usando o código de status 201 CREATEDe o cabeçalho Location: *new_profile_id*(por exemplo, 12345)

Posso então realizar atualizações alterando o estado de /profile/12345uso do verbo HTTP POST, digamos, para alterar meu endereço de e-mail ou número de telefone. Obviamente, mudando o estado do objeto remoto.

GET retornaria o status atual do /profile/12345

PUT geralmente é usado para ID gerado pelo cliente

DELETE, obvio

HEAD, obtém o status sem retornar o corpo.

Com REST, deve ser autodocumentado por meio de uma API bem projetada e, portanto, mais fácil de usar.

Este é um ótimo artigo sobre REST. Isso realmente me ajudou a entender isso também.

A especificação WSDL 2.0 também adicionou suporte para serviços da Web REST. O melhor cenário de dois mundos. O problema é que WSDL 2.0 ainda não é amplamente suportado pela maioria das ferramentas que existem. WSDL 2.0 é W3C recomendado, WSDL1.1 não é W3C recomendado, mas amplamente suportado por ferramentas e desenvolvedores. Ref: http://www.ibm.com/developerworks/library/ws-restwsdl/

A Web Application Description Language (WADL) é um vocabulário XML usado para descrever os serviços da Web RESTful.

Tal como acontece com WSDL, um cliente genérico pode carregar um arquivo WADL e ser equipado imediatamente para acessar a funcionalidade completa do serviço da Web correspondente.

Como os serviços RESTful têm interfaces mais simples, o WADL não é tão necessário para esses serviços quanto o WSDL é para os serviços SOAP no estilo RPC.