Glenn Johnson – Senior Vice President – Magic Software Americas
Nós somos muito bons em manter segredos na Magic Software. Às vezes, nós mesmos liberamos novos recursos úteis que poucas pessoas conhecem. Fizemos muito barulho, quando começamos a contemplar webservices baseados no protocolo SOAP. Na verdade, eu acho que escrevi o comunicado de imprensa em janeiro de 2002.
Aqui estamos, quase 10 anos depois, e agora o uniPaaS suporta abordagens REST (Representational State Transfer – Transferência de Estado Representacional) para Web Services e poucos de nós prestamos atenção quando esse recurso surgiu no produto com o lançamento do uniPaaS 1.9e. Mas vale a pena prestar muita atenção porque os webservices RESTful podem ser realizados sem a complexidade e a sobrecarga dos webservices SOAP.
REST não é uma novidade. Na verdade, é a forma como a Web tem trabalhado durante muito tempo, mas com algumas regras adicionais para nos ajudar.
O que são webservices RESTful?
Basicamente, um webservice RESTful é uma abordagem simples para webservices implementados utilizando HTTP e baseado nos princípios de arquitetura REST. Um WebService RESTful tem três recursos definidos:
- O endereço URL para o webservice (você pode chamá-lo de URI se quiser, é basicamente a mesma coisa). A URL é o equivalente a um nome.
- O tipo suportado de mídia de dados de Internet do webservice.
- O conjunto de operações HTTP suportado pelo webservice. Pense nisso como o verbo.
Veja a seguir como os métodos HTTP são normalmente utilizados para implementar um webservice.
Ao contrário dos webservices baseados em SOAP, não existe um protocolo da indústria para webservices RESTful. Neste sentido, é semelhante a um conceito como Service Oriented Architecture (SOA), onde um número de diferentes abordagens e protocolos podem ser usados para atingir os objetivos da arquitetura. Os webservices RESTful são baseados em protocolos W3C e OASIS estabelecidos, tais como HTTP, URL, XML, etc.
O estilo arquitetônico REST é baseado na idéia de que um cliente e servidor estão interagindo de forma desacoplada, com dados em cache através de uma interface uniforme. HTTP 1.1 foi projetado para estar de acordo com REST. Ao contrário de SOAP e XML-RPC, REST realmente não exige um novo formato de mensagem. No entanto, o XML é o tipo mais popular de formato de mensagem REST. Quando você usa XML, fica mais fácil para representar o recurso de informações em uma variedade de maneiras usando XSLT e Cascading Style Sheets (CSS).
No uniPaaS 1.9e, nós aprimoramos a capacidade dos desenvolvedores uniPaaS em empregar webservices RESTful, adicionando uma nova função: HTTPCall. Esta função pode ser usada com um servidor proxy e suporta SSL/TLS com a senha do certificado cliente protegida e esquemas de autenticação básicos e resumidos.
HTTPCall executa uma requisição HTTP e retorna os resultados. Você pode consumir serviços REST usando HTTPCall com todo e qualquer verbo. Esta função pode ser usada no lugar das funções HttpGet e HttpPost, simplificando a implementação de webservices RESTful no uniPaaS.
A sintaxe no uniPaaS para o uso de HTTPCall é a seguinte:
HTTPCall (verbo, serviço de URL, mensagem, [head1], [head2], …)
O “verbo” é uma string que indica o método. As opções incluem GET, POST, PUT, DELETE, e HEAD. Você pode obter uma lista ou um membro específico de uma coleção. POST é como uma operação de acréscimo na medida em que adiciona um membro a uma coleção. PUT substitui uma coleção inteira ou um membro especificado da coleção. DELETE apaga a coleção inteira ou um membro específico da coleção. HEAD é um cabeçalho que fornece informações de cabeçalhos adicionais.
A “URL do serviço” é a string que representa o endereço HTTP onde você irá recuperar a requisição HTTP. A função HTTPCall pode facilmente passar um nome de usuário e senha para a URL do serviço por uma abordagem segura e baseada em direitos para webservices. Por exemplo, quando um cliente uniPaaS está acessando um servidor web que exige um nome de usuário e senha, a URL deve ser HTTP: / / usuário: senha @ [URL].
O uniPaaS também suportará nomes secretos, seguindo essa abordagem: HTTP: user_secretname% /% /:%% @ pass_secretname [URL]
Obviamente, a “mensagem” é uma string com o texto da mensagem. Não há nenhuma limitação sobre o conteúdo da mensagem. Mensagens são auto-descritivas e desnacionalizadas.
O uso de “headers” é estritamente opcional e você pode incluir um maior número conforme necessário. Cada cabeçalho pode conter uma string que fornece informações de cabeçalho adicionais, conforme solicitado.
Como poderia se esperar, o HTTPCall retorna um BLOB contendo resultados quaisquer resultados de informações a partir da solicitação HTTP. Se a função falhar para fazer a conexão, um valor em branco é retornado. Você pode obter os cabeçalhos de resposta usando a função HTTPLastHeader.
A Magic Software oferece dois programas exemplo, Online e Rich Client, que detalham o uso da função HTTPCall. Procure os programas exemplo EL23 e REL23 para ter uma idéia de como essa função pode ser implementada.
Uma das desvantagens tradicionais do REST é que ele não se dá bem com arquiteturas de dados complexos como as de bancos de dados relacionais. A este respeito, usar uniPaaS te permite fazer a ponte entre REST e bancos de dados tradicionais. Com uniPaaS, a informação é trocada e representada usando webservices RESTful, ao mesmo tempo que você pode armazenar os dados da empresa em bancos de dados padrão da indústria. Defensores do REST simplesmente dirão que bancos de dados são muito complexos e deve mudar para estar de acordo com a forma como a Web funciona. Com uniPaaS, você evita o argumento completamente. Ele simplesmente funciona.