Arquitetura
A arquitetura dos web services WS-* se baseia em um protocolo bem definido, com regras precisas quanto ao formato dos dados trafegados e seguindo padrões acordados em consórcios de grandes corporações. Contrastando com isso, arquitetura dos web services REST é radicalmente diferente.
Poderíamos ilustrar as filosofias de projeto de serviços WS-* e REST com as sentenças a seguir.
WS-*: “Já temos o protocolo e os padrões, devemos definir os serviços que vamos oferecer e os documentos que desejamos trocar entre as partes.”
REST: “Vamos identificar os recursos envolvidos e utilizar extensamente os recursos do HTTP para definir um bom protocolo de interação com estes recursos.”
Estilos de acesso aos serviços
REST: Clientes interagem com os Recursos através de requisições HTTP GET, PUT, POST e DELETE
WS-*: Clientes invocam diferentes operações, com conjuntos variados de parâmetros de entrada e saída
Estilo Declarativo x Imperativo
A URI deve indicar o que você está manipulando e o método (ou verbo) HTTP indicará como você está manipulando. Neste exemplo, a URI /usuario/123456 nos indica que estamos manipulando um usuário específico. Sabendo que estamos usando o método HTTP GET, temos a clara indicação de que estamos buscando os dados deste usuário. Este estilo de invocação de serviços pode ser considerado Declarativo.
Em bons protocolos REST, a junção do método HTTP com a URI do recurso já nos indica na maioria dos casos qual é a operação sendo realizada. Assim, com um pequeno trecho do cabeçalho HTTP já somos capazes de compreender a comunicação.
Nos web services WS-*, a informação da operação que está sendo realizada fica encapsulada no corpo da requisição. Mesmo quando a camada de transporte das mensagens SOAP é HTTP, a URI não esclarece de forma alguma a operação envolvida. A informação dos serviços disponíveis fica descrita por elementos operation de um documento WSDL, geralmente em um formato fazerEssaOperacao. Esta maneira de desenvolver web services é classificada como Imperativa.