10 Consumo de serviços Web RESTful
Padrão representational state transfer
O padrão de comunicação REST se baseia no protocolo de comunicação
HTTP. Já o ponto no servidor que recebe tal requisição, trata e responde
com a informação desejada ou o resultado da ação se chama endpoint, que é
a parte exposta de um método/função que, recebendo os parâmetros neces-
sários, consegue processar o comando e retornar a informação à aplicação
que a originou. Um endpoint ainda é facilmente identi�cável por se parecer
com um endereço de uma página Web, mesclado com alguns dados enviados
juntamente ao Uniform Resource Locator (URL).
Essa troca de mensagens com transferência de representação de estado na
requisição compreende o REST (FIELDING, 2000). De acordo com Fielding,
uma requisição REST deve conter toda informação necessária para que o
servidor entenda a requisição, não podendo tirar proveito de contextos arma-
zenados nele. Assim, todo o estado é mantido pela aplicação cliente.
As principais vantagens do padrão REST incluem uma melhora na visibili-
dade, porque todos os sistemas de monitoramento não precisam observar além
da requisição para determinar sua natureza; a confiabilidade, que tem uma
melhoria considerável uma vez que o sistema pode tratar com mais facilidade
falhas parciais; e a escalabilidade, pois o estado da aplicação não é mantido no
servidor e, por isso, não precisa gerenciar o uso dos recursos compartilhados
por requisições diferentes (FIELDING, 2000).
Como desvantagem, aumenta-se o uso dos recursos de rede, pois existe a
repetição de dados transmitidos por interação, uma vez que eles não podem
ser mantidos no servidor no contexto compartilhado, bem como retira-se
desse servidor o controle sobre a consistência do comportamento da aplicação,
porque esta se torna dependente da correta implementação no lado do cliente
(FIELDING, 2000).
Preferencialmente, as requisições devem trabalhar de forma assíncrona,
pois não é garantido o tempo de retorno, que pode variar de milissegundos a
vários segundos — ou sequer retornarem por alguma falha na conexão.
Ao responder a requisição, o servidor não guardará mais as informações na
sessão, nem dará continuidade por si só. Por exemplo, o que mantém os filtros
selecionados ao pesquisar um produto em uma loja virtual na nova pesquisa
é a aplicação que o usuário está operando, sendo essa forma de operação a
característica das arquiteturas RESTful.
Consumo de serviços Web RESTful 11
O padrão RESTful é indicado quando cada chamada puder ser tratada como uma
transação em si. Se houver a necessidade de manter o estado da aplicação e uma
transação ser composta de diversas chamadas e trocas de mensagens, ou caso as
chamadas não forem condizentes com o uso do protocolo HTTP, convém utilizar o
Simple Object Access Protocol (SOAP). Para saber mais sobre esse protocolo, leia o capítulo
7.5 — Conceito Abstrato de Serviços e Exemplificação de Serviços do tipo SOAP, da
obra Redes de Computadores (CARISSIMI; ROCHOL; GRANVILLE, 2009).
Quando se prepara uma mensagem para ser enviada, no caso, convertendo
os objetos em uma forma que possa ser transmitida sobre HTTP, realiza-se
a serialização dos dados, que pode ser representada de diversas formas, as
mais comuns são o eXtended Markup Language (XML) e o JavaScript Object
Notation (JSON). A arquitetura RESTful tem os dados representados (ou
serializados) com esses dois padrões, mas o JSON, apesar do nome, é utilizado
por variadas linguagens de programação.
Padrões de serialização
O padrão XML é mais antigo, mas amplamente usado por se tratar de um
modelo mais rígido de serialização de dados, fornecendo maior segurança e
a integridade destes por ser mais pesado e complexo de manusear. Trata-se
do padrão de excelência em sistemas críticos, como bancos.
Já o modelo de notação JSON é bastante simples e legível, tornando-se o
padrão de escolha para a maioria das aplicações modernas que não exigem um
contrato rígido para a troca de mensagens. Nele, cada lado da aplicação ( front-
-end e back-end) tem a responsabilidade exclusiva de garantir a integridade
dos dados. Ele também utiliza menos dados por ser menos verboso, é mais
leve e suportado, nativamente, pelo JavaScript e por linguagens derivadas,
deixando o processo de serialização e desserialização mais fácil.
12 Consumo de serviços Web RESTful
Veja a representação de uma lista de dois cursos superiores de uma instituição em
formato XML:
<cursos>
<curso>
<nome>Análise e Desenvolvimento de Sistemas</nome>
<duracao-unidades>6</duracao-unidades>
<duracao-escala>semestre</duracao-escala>
<titulacao>Tecnólogo</titulacao>
</curso>
<curso>
<nome>Engenharia de Software</nome>
<duracao-unidades>8</duracao-unidades>
<duracao-escala>semestre</duracao-escala>
<titulacao>Bacharel</titulacao>
</curso>
</cursos>
Veja a representação de uma lista de dois cursos superiores de uma instituição no
formato JSON:
{
"cursos": [{
"nome": "Análise e Desenvolvimento de Sistemas",
"duracaoUnidade": "6",
"duracaoEscala": "semestre",
"titulacao": " Tecnólogo"
},
Consumo de serviços Web RESTful 13
{
"nome": "Engenharia de Software",
"duracaoUnidade": "8",
"duracaoEscala": "semestre",
"titulacao": "Bacharel"
}]
}
Aplicação do conceito de representational state
transfer com Ionic e TypeScript
Ao trabalhar com requisições HTTP e recursos externos à aplicação, sobretudo
quando se utiliza a internet para acessá-los, tem-se um nível relativamente
alto de incerteza. Os dados podem levar mais tempo do que o previsto para
retornar, ocorrendo uma falha de comunicação ou estando indisponíveis
naquele momento.
Assim, a aplicação deve estar apta a lidar com essa incerteza. Tanto a
assincronicidade como o tratamento de exceções são elementos indispensáveis
para o correto funcionamento de uma aplicação que faça uso das chamadas
de API. A primeira serve para que o usuário não tenha a aplicação travada
enquanto o retorno da chamada não chega, dando a sensação de lentidão ou
instabilidade. Já a segunda ocorre caso essa chamada não possa ser comple-
tada, ou não se receba resposta devido ao servidor estar ausente (off-line) ou
a conexão esteja muito instável (ou indisponível).
As chamadas aos recursos externos devem ser cuidadosamente tratadas para que
não tornem a aplicação inoperante enquanto espera o retorno das informações, nem
apresentem problemas graves caso o resultado dessa chamada não retorne, por algum
problema na rede, por exemplo. Assim, o correto tratamento dessas situações influirá
diretamente na experiência do usuário com sua aplicação.
14 Consumo de serviços Web RESTful
Por exemplo, uma API de desenvolvimento retorna os dados não reais
para desenvolvimento e testes de chamadas, chamando o endpoint http://
[Link]/todos que retorna uma lista de tarefas (to do).
A seguir, veja um exemplo de como efetuar a chamada para URI, solicitando a lista
de usuários.
Classes de modelo de dados:
Classe de serviço que efetuará a requisição: