Construindo serviços RESTful com DataSnap

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (22)  (0)

Neste artigo vamos ver como desenvolver Web APIs REST no Delphi utilizando DataSnap, com o objetivo de prover dados para outras aplicações por meio do protocolo HTTP.

Fique por dentro
Esse artigo apresentará os conceitos da arquitetura REST e como criar um serviço RESTful com DataSnap, demonstrando como utilizar melhor os métodos GET, PUT, POST e DELETE. Esse tema é útil porque permite aos desenvolvedores Delphi construírem, por exemplo, APIs web e sistemas baseados em microsserviços para modularizar grandes projetos e disponibilizá-los na internet. Além disso, os serviços criados seguindo essa arquitetura poderão ser consumidos por aplicações desenvolvidas com diversas linguagens, não se limitando a clientes Delphi.

Atualmente duas características têm se destacado e se mostrado extremamente importantes para grandes sistemas de software, tendo implicações diretas no sucesso dessas aplicações. A primeira delas, a escalabilidade, é a capacidade de se adequar de forma eficiente a diferentes demandas de uso. Ou seja, o sistema que atende normalmente um pequeno grupo de usuários deve estar apto a suprir um maior número de clientes sem que grande esforço seja necessário por parte da equipe de desenvolvimento. A segunda característica é a interoperabilidade, que indica a capacidade de um sistema de se comunicar, de forma transparente, com outros cuja estrutura não necessariamente é semelhante à sua. Por exemplo, uma aplicação desenvolvida em Delphi deve ser capaz de se comunicar com outra baseada em C# ou Java. Para que essa característica seja obtida com sucesso, é fundamental a utilização de padrões abertos, ou seja, aqueles possíveis de serem implementados em várias linguagens de programação sem dependência de um elemento específico de cada uma.

Quando se trata de sistemas web, ou que precisam ser expostos através da Web para garantir o acesso por clientes geograficamente distantes e, ainda mais, por meio de diferentes dispositivos (smartphones, PCs, tablets, etc.), a utilização de web services tem sido a principal estratégia utilizada há vários anos. Esses serviços atuam como uma camada intermediária entre o banco de dados e os clientes (aplicações que os consomem). Assim, o acesso ao armazenamento de informações, bem como ao processamento lógico inerente ao sistema em questão, é feito por meio desses web services, que oferecem uma interface simplificada e padronizada para consumo por clientes externos. A Figura 1 ilustra uma visão simplificada desse tipo de arquitetura.


Figura 1.
Arquitetura de aplicação utilizando web service

Essa estratégia visa atender à necessidade de interoperabilidade entre sistemas, no entanto, cuidados adicionais precisam ser tomados quando a escalabilidade é um fator crítico. Tomando como base essa figura, é fácil perceber que se por algum motivo o web service ficar indisponível, todo o sistema acaba sendo prejudicado e permanecerá completamente inoperante até que o serviço seja reestabelecido.

Nesse contexto surge a arquitetura de microsserviços, que ao invés de manter um único web service para suprir todas as necessidade do sistema, utiliza vários serviços menores, independentes, que proveem funcionalidades específicas. Com isso, a indisponibilidade de um microsserviço não afeta necessariamente os demais. Na Figura 2 temos uma ilustração desse tipo de arquitetura.


Figura 2.
Arquitetura de microsserviços

Nessa figura, cada um dos microsserviços é responsável por uma parte específica do sistema (autenticação de usuários, catálogo de produtos e vendas). Se, por algum motivo, o serviço de vendas ficar inoperante, o cliente ainda poderá continuar se autenticando e listando os produtos no site ou aplicativo, por exemplo, pois a infraestrutura utilizada para esse sistema deve permitir e facilitar tal isolamento entre as partes. Nesse esquema há também a presença da API Gateway, um elemento central que atua orquestrando o acesso aos microsserviços.

Além de garantir flexibilidade e escalabilidade, esse tipo de arquitetura permite que equipes multidisciplinares atuem no mesmo sistema, desenvolvendo os serviços inclusive com linguagens de programação distintas. Aqui retomamos a importância da utilização de padrões abertos, que permitam que apesar de serem feitos em Java, C# ou Delphi, por exemplo, esses serviços possam ser acessados de forma transparente pelos clientes. Nesse contexto, surge o conceito de REST.

REST

REST, sigla de Representational State Transfer, é um estilo arquitetural para aplicações web, que utiliza o protocolo HTTP para estabelecer conexão entre diferentes aplicações.

Diferentemente de mecanismos mais complexos como SOAP e WSDL, porém amplamente utilizados, principalmente em aplicações mais antigas, o REST utiliza basicamente os verbos do HTTP para definir as operações que podem ser realizadas pelos clientes. Assim, as operações de CRUD podem ser realizadas através de requisições HTTP utilizando os métodos POST, GET, PUT e DELETE.

Os serviços baseados em REST, chamados de RESTful services, devem ser independentes de plataforma e linguagem de programação. Assim, tanto a construção quanto o consumo desse tipo de serviço requerem, basicamente, que a linguagem ofereça suporte à exposição de dados e realização de requisições via protocolo HTTP.

Ao receber uma solicitação do cliente, o servidor deve respondê-la com o recurso solicitado, ou com a informação de que algum erro ocorreu, por exemplo. A resposta, nesse caso, pode ser uma página HTML, uma mensagem em texto simples, um arquivo, entre outros tipos de recursos. Para realizar o tráfego de informações estruturadas, como um objeto do domínio da aplicação (clientes, produtos, etc.), geralmente utiliza-se o formato JSON (JavaScript Object Notation). Na Figura 3 vemos um exemplo de requisição via método GET.


Figura 3.
Requisição a serviço RESTful

Observe que o cliente fez uma requisição ao servidor por meio de um URI (Uniform Resource Identifier), ou seja, um endereço único que identifica o recurso que se está tentando obter. Após receber a solicitação, o servidor possivelmente fez alguma consulta a uma base de dados, obtendo o recurso desejado, e o retornou no fo" [...]

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?