Remote Procedure Call (RPC)
É uma especificação para executar funções em um contexto diferente, através de requisições HTTP. Essa API passou por diversas versões. Sua versão mais atual é a gRPC, desenvolvida pelo Google com suporte a load balancing, tracing, health checking e autenticação. gRPC é muito útil para conectar microserviços.
Como funciona?
Uma aplicação-cliente invoca um processo remoto, serializa os parâmetros — junto de algumas informações adicionais — e envia a mensagem para o servidor. Quando recebe a mensagem, o servidor executa o processo solicitado e envia o resultado ao cliente. O processo de serialização e de-serialização é realizado por intermediários client stub e server stub.
Prós e contras
Prós
- Interação simples e clara. Apenas os verbos GET (buscar informações) e POST (todo resto) são utilizados. Os mecanismos da interação podem ser descritos como chamar um endpoint e receber uma resposta.
- Adicionar funcionalidades é fácil. Basta criar uma função e atribuí-la a um endpoint, que o cliente já poderá chama-lá.
- Alta performance. Graças as mensagens pequenas, o tráfego nas redes é leve. Além disso, RPC consegue otimizar a camada de rede para aumentar a eficiência do envio de muitas mensagens por dia.
Contras
- Alto acoplamento com o sistema. As chamadas a um servidor RPC deve ser feitas de acordo com a assinatura dos métodos. Devido a isso, informações de implementação do sistema ficam expostas. Além disso, a independência das equipes e requisitos de escalabilidade nesses sistemas, ficam muito difíceis de serem alcançados.
- Difícil exploração. Não existe uma forma de inspecionar ou enviar uma requisição para entender qual função chamar.
- Sobrecarga de funções. É tão fácil adicionar funções que ao invés de editar alguma existente, optamos por criar novas. Assim, acabamos com um amontoado de funções com tarefas similares e não sabemos mais quando usar qual.
Casos de uso
- Empresas como Google, Facebook (Apache Thrift) e Twitch (Twirp) utilizam RPC para tarefas que precisam de alta performance e baixo custo e dificuldade inicial.
- Aplicações de comandos. RPC é A Escolha para enviar comandos a um sistema remoto. A API do Slack foi modelada seguindo os princípios do RPC.
- Aplicações com alto fluxo de mensagens e necessidade de performance, que não precisem ter uma API muito grande.
Simple Objects Access Protocol (SOAP)
Utiliza XML com um padrão bem definido para adicionar algumas funcionalidades a comunicação.
Como funciona?
Toda mensagem é composta por:
- uma tag envelope que contém toda mensagem;
- um corpo contendo a requisição ou resposta;
- um cabeçalho, caso a mensagem precise definir alguma coisa;
- informações sobre erros que podem ocorrer durante o processamento do request.
Toda lógica da API SOAP está escrita em Web Service Description Language (WSDL). Com isso, qualquer um pode conhecer todos endpoints da aplicação e quais suas funções. Facilitando a utilização dessa API.
SOAP suporta mensagem com ou sem estado. Em um cenário com estado, o servidor pode armazenar uma grande massa de informações. Isso é ideal para sistemas que precisem realizar transações complexas.
Prós e contras
Prós
- Independente de linguagem e plataforma. A forma como o SOAP funciona permite que ele possa ser utilizado com qualquer linguagem ou plataforma.
- Pode usar uma variedade de protocolos. Em termos de protocolos, SOAP é bem flexível. Com isso, ele pode ser viável para muitos cenários diferentes.
- Gerenciamento interno de erros. (Não entendi como funciona.)
- Diversas extensões de segurança. Integrada aos protocolos de segurança WS-Security, SOAP fornece tudo que uma transação com qualidade do nível de grandes corporações precisa. Providencia privacidade e integridade dentro das transações enquanto permite encriptação no nível de mensagem.
Contras
- Pesado e único ao XML. As mensagens SOAP possuem muitos meta-dados. E a estrutura naturalmente extensa de um XML, contribuí para uso extensivo de rede.
- Conhecimento estritamente especializado. Construir uma API SOAP necessita de entendimento profundo de todos protocolos, suas dependências e regras altamente restritas.
- Atualização tediosa de mensagens. Alterações nas propriedades das mensagens consome muito esforço.
Casos de uso
Atualmente a arquitetura SOAP está mais presente em integrações internas de empresas ou com terceiros confiáveis.
Transmissão de dados altamente segura. A estrutura rígida e capacidades de segurança e autorização de SOAP, a tornam a melhor opção para garantir que a comunicação entre consumidor e provedor sigam o mais próximo possível definições legais. Por esse motivo organizações financeiras e outros usuários corporativos optam por SOAP.
Representational State Transfer (REST)
RESTful é um objetivo dado a aplicações que sigam as 6 regras da arquitetura REST
É uma arquitetura definida por regras arquitetônicas adaptas a muitos consumidores. A arquitetura, originalmente criada em 2000 por Roy Fielding, disponibiliza dados do servidor em representações em formatos simples, normalmente JSON ou XML.
Como funciona?
Diferente de SOAP, a arquitetura REST possuí apenas 6 regras:
- interface uniforme: possibilitando interação com o servidor de maneira idêntica em qualquer plataforma ou aplicação que a consuma;
- stateless: todos dados necessários para executar a requisição deve estar contida nela;
- caching: cache é bom;
- arquitetura cliente-servidor: permite a evolução independente de ambos lados;
- sistema em camadas: (ainda não sei);
- prover código executável ao cliente.
HATEOAS
Aplicações RESTful devem usar Hypertext As The Engine of Application State (HATEOAS). Essas aplicações retornam junto às repostas, alguns meta-dados com ações que podem ser realizadas sobre aquele recurso. Essas ações são retornadas de acordo com a disponibilidade em relação ao estado do recurso.
Aplicações que não implementam HATEOAS, deixam de seguir uma das regras REST. Por esse motivo, essas APIs podem também ser consideradas uma versão entre RPC e REST.
{ "account": { "account_number": 12345, "balance": { "currency": "usd", "value": 100.00 }, "links": { "deposit": "/accounts/12345/deposits", "withdraw": "/accounts/12345/withdraws", "transfer": "/accounts/12345/transfers", "close": "/accounts/12345" } } }
{ "account": { "account_number": 12345, "balance": { "currency": "usd", "value": -25.00 }, "links": { "deposit": "/accounts/12345/deposits", } } }
Nomenclatura
Em REST as funcionalidades devem ser implementadas conforme uma combinação do verbo HTTP e um recurso (um substantivo).
Prós e contras
Prós
- Desacoplamento cliente-servidor. A abstração de funcionalidades em recursos aumenta o isolamento da implementação, facilitando manutenção.
- Descobrimento. Se a API implementar HATEOAS, o cliente consegue descobrir como utiliza-la com quase ou nenhuma documentação.
- Cache-friendly. Com a reutilização de diversas ferramentas HTTP, REST possibilita realizar o cache de dados no nível de HTTP.
- Multiple formats support.
Contras
- Estrutura livre. Não existe um jeito correto de criar uma API REST. A modelagem de recursos e quais recursos modelar depende muito do cenário.
- Mensagens grandes. A natureza stateless e os muitos meta-dados que são enviados para que o cliente possa entender o estado da aplicação, acrescentam bastante as mensagens REST.
- Problemas com respostas pequenas e grandes. A flexibilidade de REST torna evidente problema quando faltam informações nas respostas, precisando de outra requisição para completa-la. Ou as mensagens podem ser muito grandes e trazerem informações desnecessárias.
Usos de caso
Aplicações de gerenciamento. Essas aplicações normalmente possuirão muitos consumidores. A facilidade no descobrimento facilita a vida desses consumidores. Nesse cenário também entram APIs públicas.
Aplicativos simples orientados a recursos. Quando um aplicativo não precisa de flexibilidade nas suas queries, REST é uma boa opção.
GraphQL
Essa arquitetura de API veio para solucionar os problemas causados pelo engessamento das funcionalidades por recursos em REST. Em GraphQL, você descreve na requisição exatamente o que precisa. Isso a torna ideal para uma aplicação com um modelo complexo, com muitas entidades e relacionamentos entre elas.
Como funciona?
Precisamos definir um schema. Nesse schema, estarão descritas todas queries e tipos de retorno com que a API poderá trabalhar. (Com acesso ao schema antes de criar a query, um cliente pode checar se o servidor poderá responder a ela.) Quando uma query chega ao servidor GraphQL ela é interpretada em relação ao schema inteiro. Após processar a query, a API retorna um JSON contendo apenas os dados que o cliente solicitou.
Além das funcionalidades padrão de CRUD, GraphQL possibilita que um cliente se inscreva a algum recurso para receber notificações real-time.
Prós e contras
Prós
- Alto descobrimento. Com um schema tipado, basta apontarmos um cliente a uma GraphQL API que conheceremos as queries possíveis.
- Ótima para grafos.
- Sem versionamento.
- Mensagens de erro bem detalhadas. As mensagens de erro apontam exatamente qual resolver e qual parte da query foi culpada.
- Permissões flexíveis. É possível expor de forma seletiva algumas funções e preservar informações privadas.
Contras
- Problemas de performance. A API reduz a complexidade em troca de maior uso de processamento. Em casos de muitos campos aninhados, o sistema pode ser sobrecarregado. (Então REST continua uma opção melhor para queries complexas.)
- Fazer cache é muito complexo. Sem reutilizar as semânticas do HTTP, fazer cache requer mais trabalho.
- Relativamente complexo. GraphQL tem muitas operações únicas a ele além da linguagem de criação de schemas. Isso requer um estudo prévio ao desenvolvimento.
Casos de uso
Aplicações mobile. Em casos onde a performance de rede é muito importante, GraphQL se encaixa bem. Ele disponibiliza mensagens pequenas e as requisições podem ser feitas apenas quando realmente necessário.
Também é uma opção interessante para esconder a complexidade de uma aplicação. Em sistemas legado, GraphQL possibilita esconder essa complexidade e dispondo dados conforme o cliente precisar.
Como escolher um padrão?
Normalmente a escolha de um padrão de API depende de:
- qual linguagem de programação está sendo usada;
- qual ambiente está sendo utilizado;
- quanto recurso humano e financeiro pode ser utilizado.
O padrão RPC é ótimo para micro-serviços internos, mas não muito legal para uma API externa. As funcionalidades de segurança de SOAP o tornam insubstituível em operações de cobrança, reservas e pagamento. Mesmo sendo o padrão com maior abstração e melhor modelagem de API, as mensagens grandes e constantes requisições tornam REST uma opção ruim para aplicações móveis. Nesse cenário, as requisições concisas do GraphQL ganham espaço. Porém os desenvolvedores precisam primeiro entender como utiliza-la.