15. APIs e Serviços Web

01. Introdução e Conceitos Fundamentais

Uma API (Application Programming Interface) funciona como um contrato ou uma fronteira bem definida através da qual componentes de software heterogêneos trocam dados e instruções sem a necessidade de intervenção humana na interface de usuário.

Visão de Infraestrutura de Redes: Do ponto de vista da pilha de protocolos, as APIs residem estritamente na Camada de Aplicação (Camada 7 do modelo OSI), geralmente trafegando sobre conexões confiáveis estabelecidas via TCP e seguras via TLS nas camadas inferiores.

A evolução histórica dos serviços distribuídos divide-se em marcos de acoplamento:

RPC / RMI: Acoplamento forte, dependência estrita de plataforma e binários específicos.
SOAP (Simple Object Access Protocol): Baseado em XML, fortemente tipado e com contratos rígidos (WSDL), focado no ambiente corporativo e transportado primordialmente via HTTP.
REST (Representational State Transfer): Modelo flexível focado na manipulação direta de recursos, utilizando as propriedades nativas da arquitetura Web existente.

02. Arquitetura REST (Representational State Transfer)

Criado por Roy Fielding, o REST não é um protocolo ou uma ferramenta, mas sim um estilo arquitetural governado por 6 restrições obrigatórias (constraints):

Client-Server

Separação estrita de responsabilidades: a interface gráfica (cliente) não gerencia dados; o backend (servidor) não gerencia estados de UI.

Stateless (Sem Estado)

Cada requisição isolada deve conter 100% dos dados necessários para seu processamento. O servidor não mantém contexto em sessão de memória.

Cacheable

As respostas devem explicitamente se declarar como passíveis de cache para evitar sobrecarga repetitiva na infraestrutura de rede.

Layered System

O cliente não pode discernir se está conectado diretamente ao servidor de aplicação final ou a intermediários (Load Balancers, Proxies, CDNs).

Design de Recursos e URIs: No REST, as operações expõem substantivos e recursos, nunca ações/verbos na URL:

Padrão Recomendado (Correto)	Antipadrão Comum (Incorreto)
`GET /api/v1/usuarios`	`GET /api/getUsuarios`
`DELETE /api/v1/usuarios/42`	`POST /api/usuarios/deletar?id=42`

03. O Protocolo HTTP como Motor do REST

O RESTful utiliza nativamente os mecanismos semânticos estabelecidos pelas especificações do protocolo HTTP.

Principais Verbos (Métodos) HTTP

GET Recupera a representação de um recurso. É **Seguro** e **Idempotente** (múltiplas chamadas geram o mesmo resultado sem efeitos colaterais).
POST Submete dados para criar um novo recurso secundário subordinado. Não é Idempotente.
PUT Atualiza integralmente um recurso existente ou o cria caso não exista através de ID predefinido. É Idempotente.
PATCH Aplica modificações parciais a um recurso existente.
DELETE Remove em definitivo um recurso especificado. É Idempotente.

Estrutura de Serialização de Dados

Embora o REST suporte múltiplos formatos, o JSON (JavaScript Object Notation) substituiu o XML por ser baseado em texto leve, de fácil parseamento computacional e menor consumo de banda na rede.

Exemplo Prático de Payload JSON (Requisição/Resposta):

{
  "id": 1052,
  "disciplina": "Serviços de Rede",
  "status": "Ativo",
  "carga_horaria": 80
}

04. Segurança em APIs

Devido à natureza Stateless do REST, a segurança deve ser avaliada a cada requisição entrante. Nunca se utiliza sessões de servidor vinculadas a cookies tradicionais de navegadores.

Bearer Token & JWT

O JWT (JSON Web Token) encapsula informações criptograficamente assinadas divididas em três partes (Header, Payload e Signature). É auto-contido e ideal para autenticação descentralizada em microsserviços.

OAuth 2.0

Framework de autorização de mercado que permite aplicações terceiras obterem acesso limitado a recursos do usuário, utilizando delegação de papéis complexos através de tokens de escopo específico.

05. Comunicação Assíncrona e Novas Arquiteturas

A arquitetura de sistemas evoluiu para além do modelo tradicional síncrono de Requisição/Resposta do REST:

Webhooks: Estratégia de inversão de controle baseada em eventos. O servidor dispara um gatilho via requisição HTTP POST reversa direcionada a um endpoint previamente registrado pelo cliente no momento em que um evento interno ocorre.
GraphQL: Linguagem de consulta criada pelo Facebook. Permite ao cliente ditar no corpo da requisição o esquema e formato exato dos dados que necessita receber, extinguindo problemas de Over-fetching (trazer dados inúteis) ou Under-fetching (fazer múltiplas requisições sequenciais).
gRPC: Framework RPC de alto desempenho mantido pela Google. Opera nativamente sobre canais multiplexados do **HTTP/2**, utilizando codificação binária compacta através de Protocol Buffers (Protobuf), largamente aplicado na comunicação interna de microsserviços.

Nesta Aula