Por que eu devo ler este artigo:Neste artigo serão apresentados os conceitos de REST dando uma ênfase especial em HATEOAS, uma abordagem utilizada para enriquecer a representação de recursos com links que permitem navegar entre recursos e mudar os estados da aplicação.

Também será feita uma revisão das técnicas utilizadas ao longo dos anos para fazer a integração de sistemas. Para exemplificar os conceitos abordados será apresentada uma aplicação de compras online construída com o Spring HATEOAS, uma implementação de HATEOAS feita pela Spring Foundation.

A integração de sistemas é um dos grandes desafios para muitas empresas e seus desenvolvedores. Diversas razões fazem com que essa tarefa seja complexa, tais como: envolver aplicações construídas por equipes diferentes, na maioria das vezes em empresas diferentes e em certos casos com culturas diferentes.

Além disso, existem questões técnicas envolvidas como, por exemplo: segurança, disponibilidade, desempenho, etc. Mas apesar desse cenário, as empresas se preocupam cada vez mais com integração para obter benefícios como reaproveitar funcionalidades já disponíveis nos sistemas que estão em produção e reduzir custos evitando que as informações sejam replicadas, levando à inconsistência e outros erros.

Atualmente, existem diversas formas de se fazer integração, mas a que talvez seja a mais conveniente se baseia no uso de serviço de software. De uma forma geral, um serviço consiste em basicamente disponibilizar uma funcionalidade implementada em um sistema para ser acessada por outros sistemas através de determinados protocolos e representações. Dessa forma, sempre que um sistema precisar de alguma informação mantida por outro sistema, basta que ele faça a chamada de um serviço no sistema apropriado e a resposta adequada será devolvida.

Como já sabemos, a web tem sido muito utilizada como meio de comunicação para fazer integrações. Isso se deve basicamente às próprias características da web tais como, ubiquidade e escalabilidade, além dela utilizar o protocolo HTTP que é muito simples e ao mesmo tempo versátil o suficiente para atender às demandas das empresas.

Por trás de todos os conceitos da web está o que se chama de estilo arquitetural, um conjunto de propriedades que definem as suas características. Nesse caso, estamos falando do REST (Representational State Transfer), um estilo apresentado por Roy Fielding na sua tese de doutorado em 2000.

Apesar desse conceito ter ficado adormecido por alguns anos, ele é atualmente um dos principais estilos aplicados em sistemas para fazer integrações. O REST e suas propriedades são os principais assuntos desse artigo, como será visto nas seções seguintes.

Nesse artigo, serão apresentados os principais conceitos de REST e como ele pode ser utilizado para disponibilizar os serviços de uma aplicação. Será apresentado também o HATEOAS, uma das principais propriedades do REST para fazer a navegação entre recursos, que são representações dos modelos de negócio da aplicação e também para modificar o estado da aplicação.

Ao final do artigo será apresentada uma aplicação de exemplo para demonstrar os conceitos apresentados, construída com o Spring HATEOS, um projeto do Spring Foundation. Para encerrar, será citado o HAL, Hypermedia Application Language, que define um padrão bem simples para a estrutura de representação de recursos e links do HATEOAS.

Evolução das tecnologias para integração de sistemas

A necessidade de integração entre sistemas não é nova. Durante muito tempo os desenvolvedores vêm buscando soluções para tratar desse problema, e nessa busca surgiram diversas abordagens, que vão desde integrações mais simples baseadas na troca de arquivos ou no uso de banco de dados centralizados e compartilhados por diversos sistemas, até as mais sofisticadas baseadas em camadas de serviço nas aplicações ou em ferramentas próprias de integração.

Apesar de ainda serem muito usadas, essas abordagens simples são muito limitadas e trazem diversos problemas pois elas geralmente não são padronizadas, são de difícil manutenção, não são escaláveis e podem ser muito acopladas, como no caso de integração via banco de dados. Elas certamente não são adequadas para atender às demandas das aplicações mais modernas, devido à complexidade dessas aplicações e da necessidade de haver um grande número de sistemas interligados.

Considerando a forma de integração baseada em serviços, uma tecnologia importante que surgiu em 1976 foi o RPC (Remote Procedure Call – veja a referência A High-Level Framework for Network-Based Resource Sharing na seção Links).

A ideia inicial do RPC era definir uma forma de compartilhar diversos recursos em uma rede, em particular, permitir o acesso remoto ao sistema de arquivos, mas a ideia de RPC acabou se expandindo e tornando-se uma abordagem para executar funcionalidades diversas em sistemas remotos (o meio de acesso é feito através da interface de rede, tornando assim indiferente se o processo que estamos chamando está na mesma máquina ou em uma máquina remota), ou seja, uma forma de integrar sistemas. Algumas implementações importantes de RPC são: CORBA, DCom+, RMI, SOAP, entre outras.

Apesar de funcionais, essas implementações possuem algumas limitações. DCom+ e RMI, por exemplo, são específicas de plataforma. DCom+ só permite a comunicação entre aplicações que utilizam tecnologia Microsoft. Já o RMI permite somente a comunicação entre aplicações desenvolvidas em Java.

Por outro lado, CORBA possibilita a integração entre serviços implementados em diversas linguagens e que podem ser acessar através de um sistema intermediário, um middleware, chamado ORB (Object Request Broker), que é responsável por receber as requisições dos clientes, chamar o método do objeto destino e devolver o resultado.

Apesar do CORBA ser muito flexível e poderoso, a dependência do middleware faz com que sua configuração e disponibilização se torne algo complexo para se desenvolver e manter.

Posteriormente surgiu uma versão de RMI que era executada em cima do CORBA, chamado de RMI-IIOP, e que estava disponível em alguns servidores de aplicação tal como o JBoss, que já vinha com uma versão específica de ORB, o JacORB.

Devido às dificuldades citadas anteriormente e, principalmente, pela necessidade de ambientes muito heterogêneos precisarem se comunicar, as i ...

Quer ler esse conteúdo completo? Tenha acesso completo