Questão de Arquitetura de Software — Interoperabilidade — FGV 2026
Arquitetura de Software›Interoperabilidade
Código
fg126234
Banca
FGV
Órgão
AL-GO
Ano
2026
Nível
Superior
Cargo
Analista Legislativo - Desenvolvedor de Sistemas
Com o aumento das integrações entre sistemas internos e aplicações externas, a instituição está revisando sua estratégia de comunicação entre serviços. A equipe de TI precisa garantir que as novas soluções ofereçam interoperabilidade, padronização e facilidade de manutenção. Para isso, durante a definição da arquitetura de integração, surge a necessidade de avaliar as características essenciais que uma API deve apresentar para garantir segurança, consistência e eficiência no acesso a dados e funcionalidades corporativas.Nesse sentido é válido afirmar que
Ahá oportunidades de gerar receita e benefícios através do uso de APIs, que podem ser gerenciadas e monetizadas de forma estratégica.
Buma API mantém informações sobre o estado da interação entre o cliente e o servidor ao longo do tempo, para permitir comunicações dependentes de um contexto previamente estabelecido.
Ca API permite comunicação baseada em HTTP e dependem de estados definidos, simplificando a integração entre aplicações.
Das interfaces gráficas de uma API se comunicam através de chamadas e respostas de código.
Eas APIs são protocolos exclusivos que especificam e descrevem sistemas pertencentes ao mesmo ecossistema se comunicam.
Revelar gabarito e comentário▾
GabaritoA — há oportunidades de gerar receita e benefícios através do uso de APIs, que podem ser gerenciadas e monetizadas de forma estratégica.
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”.
Interoperabilidade e APIs
Gabarito: letra A. A alternativa A reconhece que APIs podem ser estrategicamente gerenciadas e monetizadas, gerando receita e benefícios — uma visão alinhada ao conceito de economia de APIs, amplamente adotado em estratégias de integração corporativa. As demais alternativas contêm erros conceituais sobre o funcionamento das APIs.
SE LIGUE NESSA!
O contexto fornecido não aborda diretamente APIs, portanto a fundamentação abaixo baseia-se no entendimento geral do tema, com confiança reduzida.
Característica
Alternativa A (Gabarito)
Alternativa B
Alternativa C
Alternativa D
Alternativa E
Conceito central
APIs como produto digital, gerando receita e benefícios estratégicos
API mantém estado da interação cliente-servidor ao longo do tempo
API depende de estados definidos e comunicação baseada em HTTP
Interfaces gráficas de API se comunicam via chamadas e respostas de código
APIs são protocolos exclusivos para sistemas do mesmo ecossistema
Correção conceitual
✅ Correta — alinhada à API Economy (ex.: Stripe, Twilio, Google Maps)
❌ Incorreta — REST é stateless; estado é de sessão, não de API
❌ Incorreta — HTTP não é único protocolo; REST é stateless, não dependente de estado
❌ Incorreta — API é interface de programação, não gráfica; troca dados estruturados (JSON/XML)
❌ Incorreta — APIs não são protocolos exclusivos; podem integrar sistemas heterogêneos
Erro principal
Nenhum
Confunde statelessness com manutenção de estado
Confunde transporte (HTTP) com paradigma (stateful vs. stateless)
Usa "interfaces gráficas" para descrever API
Afirma exclusividade e mesmo ecossistema, ignorando interoperabilidade
Alternativa A — ✅ Correta ⟵ GABARITO
APIs modernas, especialmente no contexto de negócios, podem ser disponibilizadas como produtos digitais, permitindo que empresas gerem receita por meio de planos de acesso, cobrança por uso ou licenciamento. Esse modelo é conhecido como API Economy e está presente em plataformas como Stripe, Twilio e Google Maps. A banca explora exatamente essa faceta estratégica.
Alternativa B — ❌ Incorreta
Afirma que uma API mantém o estado da interação cliente-servidor ao longo do tempo. Na prática, o ideal arquitetural de APIs REST é a statelessness (ausência de estado): cada requisição contém todas as informações necessárias, e o servidor não armazena contexto da conversa anterior. Manter estado é característica de sessões, não de APIs propriamente ditas.
Alternativa C — ❌ Incorreta
Diz que a comunicação é baseada em HTTP e que as APIs dependem de estados definidos. Embora muitas APIs usem HTTP, existem outros protocolos (gRPC, WebSocket, AMQP). Além disso, como na alternativa B, a dependência de estados não é uma característica geral: REST é stateless. A afirmação confunde a tecnologia de transporte com o paradigma de projeto.
Alternativa D — ❌ Incorreta
Afirma que “interfaces gráficas de uma API se comunicam através de chamadas e respostas de código”. APIs são interfaces de programação (programmable), não gráficas. Quem possui interface gráfica é a aplicação cliente; a API expõe endpoints que trocam dados estruturados (JSON, XML) via chamadas de rede. O termo “interfaces gráficas” é inadequado.
Alternativa E — ❌ Incorreta
Declara que “APIs são protocolos exclusivos que especificam e descrevem sistemas pertencentes ao mesmo ecossistema se comunicam”. APIs não são protocolos, mas sim interfaces que padronizam a comunicação entre sistemas, frequentemente usando protocolos abertos (HTTP, HTTPS). Elas não são exclusivas de um ecossistema; podem ser públicas e consumidas por terceiros. A redação confusa ainda sugere que descrevem apenas sistemas do mesmo ecossistema, o que não é verdade.