Tecnologia REST ou SOAP?
O debate é entre um padrão central de Web services, denominado Soap (Simple Object Access Protocol), e um novo modelo de computação distribuída, denominado Rest (Representational State Transfer).
O modelo Rest é descrito como um estilo arquitetural para a construção de aplicativos, que impulsiona mais da atual tecnologia da Web para a transmissão de dados entre sistemas de computadores. De certo modo, o Rest utiliza os mesmos conceitos tecnológicos que são a base de um browser solicitando dados a partir de um aplicativo sendo executado em um servidor, e os aplica às comunicações entre aplicativos. A arquitetura utiliza XML, URLs e os comandos “get” e “put”, comumente utilizados na Internet.
Por outro lado, Soap cria uma camada de RPC (remote procedure call) sobre HTTP e XML. Comumente utilizado em LANs, as RPCs são uma interface de programação que permite que um aplicativo utilize os serviços de outro aplicativo em um sistema remoto. Soap utiliza a sintaxe XML para enviar comandos de texto entre aplicativos pela internet e é promovido como um padrão mais leve e com programação menos intensiva do que RPC ou tecnologias similares, como DCOM, da Microsoft.
Mas como uma tecnologia no estilo RPC, o padrão Soap leva muitos dos problemas da computação orientada a objetos para a Web. Portanto, segundo alguns especialistas, faz mais sentido incentivar tanto quanto for possível as atuais tecnologias da Web. “A Rest ?diz?: vamos fazer dos serviços na Web uma extensão do que já é bom na Web, em termos de um pequeno conjunto de verbos e de uma filosofia centrada em documentos”, declarou Scott Means, diretor executivo da Enterprise Web Machines, em Columbia, Carolina do Sul, e autor de vários livros em XML.
Por exemplo, utilizar Soap para conseguir informações sobre um funcionário pode envolver a obtenção de dados a partir de várias fontes e agrupá-los para exibição como um documento. A arquitetura Rest, por outro lado, solicitaria um documento XML contendo todas as informações e as forneceria para outro aplicativo, ou utilizaria XSLT (eXtensible Stylesheet Language Transformation) para convertê-las para HTML, para exibir em um browser.
Means argumenta que muitas informações já estão armazenadas em XML na Web e podem se tornar disponíveis como um serviço na Web, sem a construção de novos aplicativos com base em Soap. “No final, o objetivo seria uma infra-estrutura unificada, de modo que nunca houvessem esforços duplicados em termos de um sistema para fornecer recursos para uso público na internet e outro para fornecer para sites que formam parcerias”, comenta Means.
Obviamente, o modelo Rest não é nenhum remédio milagroso. O padrão Soap seria o melhor método para a abertura de um aplicativo herdado para a Web, desde que o desenvolvedor pudesse implementar um mecanismo de segurança adequado. Mas o Rest seria uma alternativa para a pilha de serviços na Web, se as companhias concordarem em avançar para adotar a arquitetura em seus sistemas de computadores, para a movimentação de documentos, tais como pedidos de compra, ?para a frente e para trás, na internet.
“É muito simples”, definiu Ronald Schmelzer, analista da companhia de pesquisas de TI, a ZapThink LLC. “Você pode fazer algumas coisas mais ?sólidas? com o Rest, e ele não tem as camadas de complexidade que os protocolos de serviços na Web têm”.
O Rest é mais simples porque tem menos ambigüidade do que a pilha de serviços na Web e tem menos pontos de falha. Os adeptos do Soap tiveram de formar um grupo separado, a Web Services Interoperability Organization, a fim de desenvolver padrões que possam garantir que os aplicativos habilitados para Soap possam se comunicar.
Contudo, o Soap e seus ?parentes? podem realizar tanto a transmissão de mensagens assíncrona como a síncrona, enquanto o Rest é melhor adequado para a transmissão de mensagens síncronas. Além disso, como muitos fabricantes aceitam a pilha de serviços na Web, mais aplicativos aceitarão Soap instalado, facilitando para os desenvolvedores a tarefa de associar os produtos de software na internet, utilizando Soap.
Os adeptos de Rest argumentam que sua arquitetura preferida permite que um departamento de TI seja menos dependente dos fabricantes, evitando a pilha de tecnologia de serviços na Web, que inclui Soap, WSDL e UDDI.
Todavia, as grandes companhias não se envolverão em assuntos polêmicos e, mais provavelmente, ficarão com a opção que tiver maior apoio dos fabricantes. A pilha de serviços emergentes baseados na Web é apoiada por todos os principais fabricantes. “As empresas optarão pelas apostas mais seguras – e a aposta mais segura, para ser honesto – é a pilha de serviços na Web”, acrescentou Schmelzer.
