Api Styles

• Api Styles

An API style is like a secret handshake 🤝 between two computers, helping them share and understand each other's messages. There are various methods of handshakes and each has its own way of sending and receiving information!

Here are the 6 most important API styles you need to know:

1️⃣ SOAP 🧼

An XML-based communication protocol with strict contracts. It's mostly used over HTTP(S) 🌐 and is popular in enterprise environments 🏢.

What Engineers need to know: As a software or DevOps engineer, understanding SOAP is crucial for working in enterprise environments, especially where legacy systems still exist.

2️⃣ REST API 🔄

An easy-to-understand, resource-focused API style. It uses standard HTTP methods 🌐 and often employs JSON for data.

What Engineers need to know: REST APIs are common, so mastery of their design and use is a key skill for developers and DevOps.

3️⃣ gRPC ⚙️

An API style emphasizing remote procedure calls (RPCs). It uses HTTP/2 for transport and Protocol Buffers for data serialization, making it ideal for efficient, low-latency microservices 🔬.

What Engineers need to know: Knowledge of gRPC can help in designing and maintaining high-performing, scalable microservices.

4️⃣ GraphQL 📊

A flexible query language for APIs allowing clients to request specific data. It was developed by Facebook and can combine data from multiple sources 🔄.

What Engineers need to know: Understanding GraphQL can help in creating efficient APIs that prevent over-fetching and under-fetching of data.

5️⃣ Websocket 🔌

A protocol for real-time, bidirectional communication 🔄. It maintains a long-lived connection and is great for web apps needing live updates 📲.

What Engineers need to know: Websockets are essential for applications requiring real-time data exchange, like chat applications or real-time analytics.

6️⃣ Webhook 🎣

A server-side, event-driven mechanism. It sends HTTP callbacks (usually POST requests) when specific events occur, perfect for real-time data updates or third-party service integration 🔗.

What Engineers need to know: Webhooks are crucial for setting up automated workflows and integrations, a common task in DevOps and software development.

To stay ahead of the curve, software and DevOps engineers need to understand these API styles, their benefits, and their use cases. This will allow them to design and implement efficient, scalable, and functional systems. 🚀💻

Diferenças

Qual é a diferença entre gRPC e REST?

gRPC e REST são duas formas de criar uma API. Uma API é um mecanismo que permite que dois componentes de software se comuniquem usando um conjunto de definições e protocolos. No gRPC, um componente (o cliente) chama ou invoca funções específicas em outro componente de software (o servidor). Na REST, em vez de chamar funções, o cliente solicita ou atualiza os dados no servidor.

Leia sobre APIs »

O que é gRPC?

O gRPC é uma arquitetura e um sistema de API de código aberto controlados pela Cloud Native Computing Foundation. Ele é baseado no modelo de Chamada de Procedimento Remoto (RPC). Embora o modelo RPC seja amplo, o gRPC é uma implementação específica.

O que é RPC?

Na RPC, as comunicações cliente-servidor funcionam como se as solicitações da API do cliente fossem uma operação local ou como se a solicitação fosse um código interno do servidor.

Na RPC, um cliente envia uma solicitação para um processo no servidor que está sempre ouvindo chamadas remotas. Na solicitação, ele contém a função do servidor a ser chamada, junto com todos os parâmetros a serem transmitidos. Uma API RPC usa um protocolo como HTTP, TCP ou UDP como o mecanismo subjacente de troca de dados.

Como a gRPC é diferente da RPC?

A gRPC é um sistema que implementa a RPC tradicional com algumas otimizações. Por exemplo, o gRPC usa buffers de protocolo e HTTP 2 para a transmissão de dados.

Ele também abstrai o mecanismo de troca de dados do desenvolvedor. Por exemplo, outra implementação da API RPC muito usada, a OpenAPI, exige que os desenvolvedores mapeiem os conceitos de RPC para o protocolo HTTP. Mas o gRPC abstrai a comunicação HTTP subjacente. Essas otimizações tornam o gRPC mais rápido, fácil de implementar e mais compatível com a Web do que outras implementações de RPC.

O que é REST?

REST é uma abordagem de arquitetura de software que define um conjunto de regras para trocar dados entre componentes de software. Ele é baseado em HTTP, o protocolo de comunicação padrão da Web. As APIs RESTful gerenciam as comunicações entre um cliente e um servidor por meio de verbos HTTP, como POST, GET, PUT e DELETE para operações de criação, leitura, atualização e exclusão. O recurso do lado do servidor é identificado por uma URL conhecida como endpoint.

A REST funciona da seguinte maneira:

1. O cliente faz uma solicitação para criar, modificar ou excluir um recurso no servidor
2. A solicitação contém o endpoint do recurso e também pode incluir parâmetros adicionais
3. O servidor responde, devolvendo todo o recurso ao cliente quando a operação for concluída
4. A resposta contém dados no formato JSON e códigos de status

As APIs criadas usando orientações REST são chamadas de APIs RESTful ou APIs REST.

Leia sobre APIs RESTful »

Por que as organizações usam gRPC e REST?

gRPC e REST são duas abordagens diferentes para o desenvolvimento de APIs.

Uma API funciona de forma semelhante a um pedido de comida em um restaurante por meio de um menu. Em qualquer restaurante, um cliente (cliente) pode pedir comida do menu (API), que tem um conjunto fixo de pratos. Isso é comunicado à cozinha (servidor) que prepara o prato solicitado e o envia ao cliente. O cliente não precisa saber como a cozinha preparou o pedido, apenas o que esperar em retorno. A padronização dos formatos de menu significa que os clientes e as cozinhas sabem como usá-los.

Sem APIs, não haveria um acordo compartilhado sobre como diferentes aplicações ou serviços de software se comunicam. Programadores de duas aplicações separadas precisariam falar um com o outro para determinar como desenvolver a troca de dados todas as vezes.

Existem diferentes tipos de arquiteturas de API, como gRPC e REST, pois arquiteturas diferentes podem ser melhores para diferentes casos de uso em uma organização. Um designer de API deve escolher sua arquitetura cliente-servidor preferida com base nos requisitos do sistema.

Quais são as semelhanças entre a gRPC e a REST?

REST e gRPC compartilham algumas semelhanças inatas com as abordagens arquitetônicas da API.

Mecanismo de troca de dados

Ambos permitem que dois componentes de software, um cliente e um servidor, se comuniquem e troquem dados com base em um conjunto compartilhado de regras. Essas regras se aplicam independentemente de como cada componente de software opera internamente.

Comunicação baseada em HTTP

Ambos transmitem dados por meio do mecanismo HTTP de solicitação-resposta, o protocolo de comunicação eficiente preferido da Web. No entanto, na gRPC, isso está oculto para o desenvolvedor, enquanto na REST é mais aparente.

Flexibilidade de implementação

Você pode implementar REST e gRPC em uma ampla variedade de linguagens de programação. Essa qualidade os torna altamente portáteis em todos os ambientes de programação. Isso leva a uma interoperabilidade ideal com suporte quase universal.

Adequação para sistemas distribuídos e escaláveis

Tanto a gRPC quanto a REST usam o seguinte:

• Comunicação assíncrona, para que o cliente e o servidor possam se comunicar sem interromper as operações
• Design sem estado, para que o servidor não precise se lembrar do estado do cliente

Isso significa que os desenvolvedores podem usar gRPC e REST para criar sistemas resistentes a falhas com um grande número de solicitações simultâneas. Você pode criar sistemas distribuídos e escaláveis com vários clientes.

Princípios da arquitetura: gRPC versus REST

Embora REST e gRPC ofereçam uma função semelhante, os modelos subjacentes diferem significativamente em sua arquitetura.

Modelo de comunicação

Usando uma API REST, um cliente envia uma única solicitação da API REST para um servidor, e o servidor então retorna uma única resposta. O cliente deve esperar que o servidor responda antes de continuar as operações. Esse mecanismo é um modelo de solicitação-resposta e é uma conexão de dados unária (um para um).

Por outro lado, com o gRPC, um cliente pode enviar uma ou várias solicitações de API ao servidor, o que pode resultar em uma ou várias respostas do servidor. As conexões de dados podem ser unárias (um para um), streaming de servidor (um para muitos), streaming de cliente (muitos para um) ou streaming bidirecional (muitos para muitos). Esse mecanismo é um modelo de comunicação de resposta do cliente e é possível porque o gRPC é baseado em HTTP 2.

Operações que podem ser chamadas no servidor

Em uma API gRPC, as operações de servidor que podem ser chamadas são definidas por serviços, também conhecidos como funções ou procedimentos. O cliente gRPC invoca essas funções da mesma forma como você chamaria uma função internamente em uma aplicação. Isso é conhecido como design orientado a serviços. Veja abaixo um exemplo:

createNewOrder(customer_id, item_id, item_quantity) -> order_id

Na REST, há um conjunto limitado de verbos de solicitação HTTP que o cliente pode usar em recursos do servidor definidos por uma URL. O cliente chama o próprio recurso. Isso é conhecido como design orientado a entidades. O design orientado a entidades se alinha bem com os métodos de programação orientados a objetos. Veja abaixo um exemplo:

*POST /pedidos <headers> (customer_id, item_id, item_quantity) -> order_id*

Embora você possa projetar APIs gRPC em uma abordagem orientada a entidades, isso não é uma restrição do próprio sistema.

Formato de troca de dados

Com uma API REST, as estruturas de dados passadas entre os componentes do software geralmente são expressas no formato de troca de dados JSON. É possível passar outros formatos de dados, como XML e HTML. O JSON é flexível e fácil de ler, embora deva ser serializado e traduzido para uma linguagem de programação.

Por outro lado, o gRPC usa o formato Protocol Buffers (Protobuf) por padrão, embora também ofereça suporte nativo a JSON. O servidor define uma estrutura de dados usando a linguagem de descrição da interface (IDL) do Protocol Buffer em um arquivo de proto-especificação. O gRPC então serializa a estrutura em formato binário e a desserializa para qualquer linguagem de programação especificada. Esse mecanismo o torna mais rápido do que usar o JSON, que não é compactado durante a transmissão. Os buffers de protocolo não são legíveis por humanos, ao contrário de uma API REST usada com JSON.

Leia sobre JSON »

Outras diferenças importantes: gRPC versus REST

Outras diferenças importantes: gRPC versus REST

Além do estilo arquitetônico, a gRPC e a REST têm outras diferenças inerentes.

Acoplamento cliente-servidor

A REST é frouxamente acoplada, o que significa que o cliente e o servidor não precisam saber nada sobre a implementação um do outro. Esse acoplamento fraco facilita a evolução da API ao longo do tempo. Isso ocorre porque uma alteração nas definições do servidor não exige necessariamente uma alteração no código do cliente.

O gRPC é fortemente acoplado, o que significa que o cliente e o servidor devem ter acesso ao mesmo arquivo proto. Qualquer atualização no arquivo exige atualizações no servidor e no cliente.

Geração de código

O gRPC oferece uma seleção integrada de recursos de geração de código nativo do lado do cliente e do lado do servidor. Eles estão disponíveis em vários idiomas devido ao protoc, o compilador Protocol Buffers. Depois de definir a estrutura no arquivo proto, o gRPC gera o código do lado do cliente e do lado do servidor. A geração de código torna o desenvolvimento de APIs menos demorado.

Por outro lado, a REST não oferece nenhum mecanismo integrado de geração de código, portanto, os desenvolvedores devem usar ferramentas adicionais de terceiros se precisarem desse recurso.

Streaming bidirecional

O gRPC oferece comunicação de streaming bidirecional. Isso significa que tanto o cliente quanto o servidor podem enviar e receber várias solicitações e respostas simultaneamente em uma única conexão.

A REST não oferece esse recurso.

Quando usar o gRPC versus REST

Atualmente, a REST é a arquitetura de API mais popular para serviços Web e arquiteturas de microsserviços. A popularidade da REST se deve à sua implementação simples e ao mapeamento, legibilidade e flexibilidade da estrutura de dados. É fácil para novos programadores começarem a desenvolver APIs RESTful para suas aplicações, seja para desenvolvimento de serviços Web ou microsserviços internos.

Aqui estão os casos de uso de uma API REST:

• Arquiteturas baseadas na Web
• APIs voltadas para o público para facilitar a compreensão por usuários externos
• Comunicações de dados simples

A gRPC, diferentemente da REST, foi projetada especificamente para permitir que os desenvolvedores criem APIs de alta performance para arquiteturas de microsserviços em datacenters distribuídos. É mais adequado para sistemas internos que exigem streaming em tempo real e grandes cargas de dados. O gRPC também é uma boa opção para arquiteturas de microsserviços compostas por várias linguagens de programação, quando for improvável que a API mude com o tempo.

Uma API gRPC é melhor para estes casos de uso:

• Sistemas seguros e de alta performance
• Altas cargas de dados
• Aplicações em tempo real ou de streaming

Uma nota sobre o desenvolvimento de software na Web

Embora o HTTP seja o principal protocolo da Web, existem diferentes versões do HTTP com vários graus de adoção em navegadores e servidores Web.

Uma API gRPC sempre usa HTTP 2, e uma API REST normalmente usa HTTP 1.1, que não é o mesmo protocolo HTTP. Embora o HTTP 2 agora seja um protocolo Web comum, ele não tem suporte universal para navegadores, ao contrário do HTTP 1.1. Esse suporte limitado ao navegador pode tornar o gRPC uma opção menos atraente para desenvolvedores que desejam oferecer suporte a aplicações Web.

Resumo das diferenças: gRPC versus REST

	gRPC API	API REST
O que é isso?	Um sistema para criar e usar APIs com base no modelo de comunicação cliente-servidor da Chamada de Procedimento Remoto (RPC).	Um conjunto de regras que define a troca estruturada de dados entre um cliente e um servidor.
Abordagem de projeto	Design orientado a serviços. O cliente solicita que o servidor execute um serviço ou uma função que pode ou não afetar os recursos do servidor.	Design orientado a entidades. O cliente solicita que o servidor crie, compartilhe ou modifique recursos.
Modelo de comunicação	Várias opções como unário, um servidor para vários clientes, um cliente para vários servidores e muitos clientes para vários servidores.	Unário. Um único cliente se comunica com um único servidor.
Implementação	Requer o software gRPC no lado do cliente e do servidor para operar.	Você pode implementá-lo no lado do cliente e do servidor em uma ampla variedade de formatos sem a necessidade de um software comum.
Acesso aos dados	Chamadas de serviço (função).	Vários endpoints na forma de URLs para definir recursos.
Dados retornados	No tipo de retorno fixo do serviço, conforme definido no arquivo Protocol Buffer.	Em uma estrutura fixa (normalmente JSON), definida pelo servidor.
Acoplamento cliente-servidor	Firmemente acoplado. Tanto o cliente quanto o servidor precisam do mesmo arquivo de buffer de protocolo que define o formato dos dados.	Frouxamente acoplado. O cliente e o servidor não estão cientes dos detalhes internos.
Geração automática de código	Recurso integrado.	Requer ferramentas de terceiros.
Streaming bidirecional	Presente.	Não está presente.
Mais adequada para	Arquiteturas de microsserviços de alta performance ou com muitos dados.	Fontes de dados simples, nas quais os recursos são bem definidos.