Web Services

Este material complementa os slides do Tópico 07 e apresenta uma visão estruturada sobre Web Services, seu papel na integração entre sistemas e as tecnologias mais comuns para construir aplicações backend acessíveis pela Web.

Mais do que decorar nomes como REST, SOAP ou gRPC, o objetivo aqui é entender por que serviços existem, como se comunicam e quais decisões arquiteturais afetam interoperabilidade, desempenho e manutenção.

1. O que são Web Services?

Um Web Service é um serviço de software exposto por uma aplicação para que outro sistema possa consumi-lo por meio de uma rede, geralmente utilizando protocolos da pilha Web, como HTTP e HTTPS.

Na prática, isso significa que uma aplicação pode disponibilizar funcionalidades como:

• consultar produtos;
• registrar usuários;
• processar pagamentos;
• gerar previsões meteorológicas;
• integrar dados com sistemas externos.

Um Web Service normalmente não é consumido diretamente por pessoas, mas sim por:

• aplicações frontend;
• aplicativos mobile;
• outros sistemas corporativos;
• microsserviços;
• scripts de automação e integrações.

2. Por que Web Services são importantes?

Sistemas modernos raramente funcionam isolados. Uma loja virtual, por exemplo, pode depender de vários serviços diferentes:

• um serviço para autenticação;
• outro para catálogo de produtos;
• outro para pagamentos;
• outro para cálculo de frete;
• outro para notificações por e-mail ou WhatsApp.

Os Web Services permitem que esses sistemas conversem entre si de forma padronizada, reduzindo acoplamento e ampliando a possibilidade de integração com tecnologias diferentes.

3. Características principais

3.1 Interoperabilidade

Um Web Service deve poder ser consumido por clientes implementados em linguagens, sistemas operacionais e plataformas diferentes.

Exemplo:

• backend em Java com Spring;
• aplicativo mobile em Kotlin;
• painel administrativo em React;
• serviço parceiro em Python.

Se todos seguem o mesmo contrato de comunicação, conseguem interoperar mesmo com stacks diferentes.

3.2 Portabilidade

A lógica do serviço pode ser implantada em ambientes diferentes, como máquinas locais, servidores próprios, VPS ou nuvem, sem exigir mudanças significativas para quem consome a API.

Na prática, clientes acessam um contrato exposto por URL, protocolo e formato de dados, e não a implementação interna do serviço.

3.3 Escalabilidade

Web Services podem ser projetados para atender muitos clientes simultaneamente, usando técnicas como:

• balanceamento de carga;
• cache;
• filas;
• replicação;
• conteinerização e orquestração.

4. Web Service x Web API

Os termos costumam aparecer como sinônimos, mas existe uma nuance útil:

• Web Service enfatiza o serviço exposto pela rede;
• Web API enfatiza a interface pública usada para acessar esse serviço.

Em contexto profissional, especialmente em desenvolvimento moderno, Web API é o termo mais frequente para serviços HTTP que expõem dados e operações para outros sistemas.

Exemplo:

• o sistema de mapas do Google expõe uma API;
• esse recurso é entregue por meio de um serviço acessível pela Web.

5. Exemplos reais de Web APIs

Alguns serviços amplamente utilizados na indústria:

• Google Maps API: mapas, geolocalização e rotas;
• OpenWeather API: dados meteorológicos;
• OpenAI API: modelos de linguagem e geração multimodal;
• GitHub API: repositórios, issues, pull requests e automações;
• Stripe API: pagamentos, assinaturas e faturamento.

Esses exemplos mostram que Web Services não se limitam a páginas HTML. Eles também operam como infraestrutura para integrações e produtos digitais completos.

6. Protocolos de comunicação

Na disciplina, o foco principal está em serviços acessados por HTTP e HTTPS.

6.1 HTTP

O HTTP é o protocolo de aplicação mais usado para comunicação entre cliente e servidor na Web. Ele organiza a troca de mensagens em requisições e respostas.

Exemplo conceitual:

GET /produtos/10 HTTP/1.1
Host: api.exemplo.com
Accept: application/json

Resposta:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 10,
  "nome": "Teclado"
}

6.2 HTTPS

O HTTPS é o HTTP executado sobre uma camada segura com TLS. Isso adiciona:

• confidencialidade;
• integridade;
• autenticação do servidor.

Em produção, o uso de HTTPS é praticamente obrigatório para APIs públicas e sistemas que lidam com autenticação, dados sensíveis ou transações.

7. Formatos de dados

Para que clientes diferentes consigam interpretar a informação trocada, o conteúdo precisa ser serializado em um formato padronizado.

Formatos comuns:

• JSON;
• XML;
• YAML;
• CSV;
• text/plain.

7.1 JSON

Hoje é o formato mais comum em APIs HTTP modernas.

{
  "nome": "Mouse",
  "preco": 89.9,
  "disponivel": true
}

Vantagens:

• leve;
• simples de ler;
• compatível com praticamente toda linguagem moderna.

7.2 XML

Muito usado em integrações legadas e em padrões como SOAP.

<produto>
  <nome>Mouse</nome>
  <preco>89.90</preco>
</produto>

Embora seja mais verboso que JSON, ainda aparece bastante em ambientes corporativos e integrações governamentais.

8. Estilos e arquiteturas de serviço

Há várias formas de estruturar serviços. Nem todas são “arquiteturas” no sentido estrito, mas representam abordagens importantes de comunicação entre sistemas.

8.1 SOAP

SOAP é um protocolo padronizado de troca de mensagens, normalmente usando XML. Ele foi muito adotado em sistemas corporativos porque oferece contratos formais e padrões adicionais para segurança, transações e confiabilidade.

Características:

• forte padronização;
• mensagens em XML;
• integração comum com WSDL;
• frequente em sistemas legados e integrações enterprise.

8.2 REST

REST é um estilo arquitetural baseado em recursos identificados por URLs e manipulados por métodos HTTP, como GET, POST, PUT e DELETE.

Exemplo:

• GET /produtos lista produtos;
• GET /produtos/10 detalha um produto;
• POST /produtos cria um produto;
• DELETE /produtos/10 remove um produto.

Hoje, APIs REST com JSON são o padrão mais frequente em aplicações web e mobile.

8.3 gRPC

gRPC é uma tecnologia de comunicação remota baseada em contratos definidos com Protocol Buffers. Ela costuma ser usada em comunicação entre serviços, com foco em desempenho e tipagem forte.

Vantagens:

• alta performance;
• contratos explícitos;
• suporte a streaming;
• boa interoperabilidade entre linguagens.

8.4 GraphQL

GraphQL é uma linguagem de consulta e um runtime para APIs. Em vez de vários endpoints fixos, o cliente consulta exatamente os campos de que precisa.

Ele é útil quando:

• há muitos relacionamentos entre dados;
• diferentes clientes precisam de projeções diferentes;
• deseja-se reduzir overfetching e underfetching.

8.5 WebSocket

WebSocket não é um estilo arquitetural no mesmo nível de REST ou SOAP, mas um protocolo para comunicação bidirecional e persistente entre cliente e servidor.

É útil em cenários como:

• chats;
• jogos online;
• dashboards em tempo real;
• notificações instantâneas.

9. Comparando abordagens de comunicação

Cada tecnologia atende melhor a contextos diferentes.

Tecnologia	Formato mais comum	Melhor uso
REST	JSON	APIs CRUD, integração web e mobile
SOAP	XML	Integrações corporativas com contrato formal
gRPC	Protocol Buffers	Comunicação entre serviços com foco em desempenho
GraphQL	JSON	Consultas flexíveis com diferentes necessidades de cliente
WebSocket	Frames persistentes	Atualizações em tempo real

Essa comparação ajuda a evitar a ideia de que existe uma única solução ideal para todos os cenários.

10. Exemplo de contrato de API

Um contrato de API define como clientes e servidores se comunicam. Isso inclui rota, método HTTP, formato do corpo, cabeçalhos e status esperados.

Requisição:

POST /produtos HTTP/1.1
Host: api.exemplo.com
Content-Type: application/json

{
  "nome": "Mouse Gamer",
  "preco": 149.90
}

Resposta esperada:

HTTP/1.1 201 Created
Content-Type: application/json

{
  "id": 101,
  "nome": "Mouse Gamer",
  "preco": 149.90
}

Quando esse contrato é bem definido, clientes diferentes conseguem consumir o serviço com previsibilidade.

11. Frameworks para criar Web Services

Frameworks oferecem abstrações prontas para receber requisições, definir rotas, validar dados, serializar respostas e integrar com banco de dados.

Alguns exemplos:

• Spring Web para Java;
• NestJS e Express para Node.js;
• Flask para Python;
• Laravel para PHP.

11.1 Exemplo com Spring Web

@RestController
public class HelloWorldController {
    @GetMapping("/")
    public String olaMundo() {
        return "Ola mundo";
    }
}

11.2 Exemplo com NestJS

import { Controller, Get } from '@nestjs/common';

@Controller()
export class AppController {
  @Get()
  getHello(): string {
    return 'Hello World!';
  }
}

11.3 Exemplo com Express

const express = require('express');
const app = express();

app.get('/', (req, res) => {
  res.send('Hello World!');
});

app.listen(3000, () => {
  console.log('Servidor em execucao na porta 3000');
});

Independentemente da linguagem, a ideia é a mesma: expor um endpoint que recebe uma requisição e devolve uma resposta.

12. Monolitos e microsserviços

Ao desenvolver Web Services, duas abordagens arquiteturais aparecem com frequência.

12.1 Monolito

No modelo monolítico, várias funcionalidades da aplicação ficam no mesmo projeto e geralmente são implantadas juntas.

Vantagens:

• simplicidade inicial;
• menos complexidade operacional;
• fácil desenvolvimento em projetos pequenos.

Desvantagens:

• crescimento pode dificultar manutenção;
• deploy único para todo o sistema;
• maior acoplamento entre módulos.

12.2 Microsserviços

No modelo de microsserviços, o sistema é dividido em serviços menores e especializados.

Vantagens:

• escalabilidade mais granular;
• autonomia entre times;
• deploy independente por serviço.

Desvantagens:

• maior complexidade de infraestrutura;
• desafios de observabilidade e segurança;
• comunicação distribuída mais difícil.

Em muitas situações educacionais e em projetos pequenos, começar com um monolito bem organizado é mais saudável do que adotar microsserviços cedo demais.

13. Deploy de Web Services

Depois de implementado, um serviço precisa ser disponibilizado em uma infraestrutura acessível pela rede.

Opções comuns:

• servidor físico: máquina própria gerenciada localmente;
• VPS: servidor virtual alugado de um provedor;
• nuvem: serviços gerenciados ou infraestrutura em provedores como AWS, Azure e Google Cloud.

Além da hospedagem, deploy de APIs costuma envolver:

• configuração de domínio;
• certificados TLS;
• variáveis de ambiente;
• banco de dados;
• logs e monitoramento.

14. Boas práticas para Web Services

• Definir contratos de entrada e saída com clareza.
• Escolher códigos HTTP coerentes com o resultado da operação.
• Validar dados recebidos antes de processá-los.
• Evitar expor detalhes internos desnecessários.
• Versionar APIs quando mudanças quebrarem compatibilidade.
• Documentar endpoints, formatos e exemplos de uso.

15. Conclusão

Neste tópico você viu que Web Services são a base da integração entre aplicações modernas. Eles permitem interoperabilidade entre plataformas, expõem funcionalidades pela rede e podem adotar diferentes abordagens, como REST, SOAP, gRPC, GraphQL e WebSocket, dependendo do contexto.

Também vimos que frameworks simplificam a implementação, e que decisões de arquitetura, formato de dados e infraestrutura afetam diretamente manutenção, desempenho e capacidade de evolução dos sistemas.

16. Materiais de apoio

• MDN Web Docs - HTTP Overview: https://developer.mozilla.org/en-US/docs/Web/HTTP/Overview
• REST Resource Naming Guide: https://restfulapi.net/resource-naming/
• GraphQL Learn: https://graphql.org/learn/
• gRPC Introduction: https://grpc.io/docs/what-is-grpc/
• SOAP 1.2 Part 0 Primer (W3C): https://www.w3.org/TR/soap12-part0/