Questão de Arquitetura de Software — Conceitos Básicos em Arquitetura de Software — FGV 2026
Arquitetura de Software›Conceitos Básicos em Arquitetura de Software
Código
fg133922
Banca
FGV
Órgão
TJ-RJ
Ano
2026
Nível
Superior
Cargo
Analista Judiciário - Tecnologia da Informação - Analista de Sistemas
Como arquiteto de software, Pedro optou por adotar um estilo arquitetural híbrido derivado de vários outros. Analisando as vantagens e desvantagens do estilo Representational State Transfer (REST), Pedro observou como vantagem:
Ao cache no cliente, que aumenta a confiabilidade já que mantém os dados atualizados;
Ba escalabilidade, visto que o servidor não precisa gerenciar a utilização de recursos entre as solicitações;
Co encapsulamento da funcionalidade de chamada de procedimento remoto utilizando a flexibilidade do XML;
Do contexto único por cliente, graças ao controle de sessões mantido no servidor, visto que não é permitido ao cliente manter o estado sessão;
Ea interface uniforme que previne que o processamento de mensagens REST não inicie até que o nó tenha identificado todos os blocos obrigatórios de cabeçalho.
Revelar gabarito e comentário▾
GabaritoB — a escalabilidade, visto que o servidor não precisa gerenciar a utilização de recursos entre as solicitações;
Comentário gerado por IA. É um apoio ao estudo, ancorado em fontes, mas pode conter imprecisões — confira sempre na fonte oficial (lei, súmula, edital e gabarito da banca). Encontrou um erro? Use “Reportar”.
REST (Representational State Transfer) — Vantagens
Gabarito: letra B. A escalabilidade é uma vantagem reconhecida do REST porque o estilo é stateless: o servidor não mantém estado de sessão entre requisições, logo não precisa gerenciar a alocação de recursos entre solicitações, permitindo que cada requisição seja tratada de forma independente e distribuída horizontalmente com facilidade.
A banca testa o conhecimento das características centrais do REST, especialmente a restrição de statelessness (ausência de estado). Vamos analisar cada alternativa:
Alternativa A — ❌ Incorreta
O cache no cliente não aumenta a confiabilidade quanto à atualização dos dados, pois dados em cache podem ficar desatualizados (stale). O cache melhora desempenho e reduz latência, mas a confiabilidade dos dados depende de mecanismos de invalidação (ex.: cabeçalhos Cache-Control). Além disso, manter dados atualizados não é consequência direta do cache.
Alternativa B — ✅ Correta ⟵ GABARITO
O REST é stateless: cada requisição do cliente contém toda a informação necessária para ser processada, e o servidor não mantém nenhum contexto de sessão. Isso elimina a necessidade de gerenciar estado entre requisições, simplificando o servidor e permitindo escalabilidade horizontal (balanceamento de carga) sem esforço adicional. A frase "não precisa gerenciar a utilização de recursos entre as solicitações" descreve exatamente essa vantagem.
Alternativa C — ❌ Incorreta
Esta alternativa descreve a chamada de procedimento remoto (RPC) encapsulada em XML, que é característica do estilo arquitetural SOAP (ou XML-RPC), não do REST. REST é baseado em recursos (resources) e usa métodos HTTP padronizados (GET, POST, PUT, DELETE), não invocação de procedimentos remotos.
Alternativa D — ❌ Incorreta
REST é stateless: o servidor não mantém contexto de sessão por cliente. A afirmação de que o servidor mantém controle de sessões e que "não é permitido ao cliente manter o estado sessão" inverte o correto. Na verdade, o cliente é responsável por enviar todo o estado necessário em cada requisição (ex.: tokens de autenticação). Não há "contexto único por cliente" mantido pelo servidor.
NÃO CAIA NESSA!
A alternativa D inverte o princípio de statelessness, afirmando que o servidor mantém sessões e que o cliente não pode manter estado. No REST, é exatamente o oposto: o servidor não gerencia sessão, e o cliente mantém o estado (ou o envia a cada requisição). Cuidado para não confundir!
Alternativa E — ❌ Incorreta
A interface uniforme é um dos princípios do REST (identificação de recursos, manipulação via representações, mensagens autodescritivas, HATEOAS). No entanto, ela não "previne que o processamento de mensagens REST não inicie até que o nó tenha identificado todos os blocos obrigatórios de cabeçalho". Isso não é uma definição válida e não corresponde a nenhuma característica real do REST.
PEGA ESSA DICA!
Para questões sobre REST, lembre-se dos seis vínculos (constraints) propostos por Fielding: cliente-servidor, stateless, cache, interface uniforme, sistema em camadas e código sob demanda (opcional). A ausência de estado (stateless) é a chave para escalabilidade — decore que o servidor não gerencia sessão.