Questão de Arquitetura de Software — WebServices — FCC 2026
Arquitetura de Software›WebServices
Código
gp045409
Banca
FCC
Órgão
MPE-AL
Ano
2026
Cargo
Analista do Ministério Público - Especialidade: Desenvolvimento de Sistemas
Uma equipe de desenvolvimento implementou a integração entre o sistema interno de gestão de protocolos e uma API externa responsável pelo cadastro e atualização de dados de cidadãos. A aplicação cliente realiza requisições HTTP utilizando exclusivamente o método POST para todas as operações, inclusive consultas, sem o corpo da requisição em campo denominado acao, o qual indica o tipo de operação a ser executada. Em revisão junto ao arquiteto de soluções REST, durante revisão arquitetural, foi solicitado que a integração evoluísse para maior aderência ao estilo arquitetural REST.À luz dos princípios do padrão REST, a adequação arquitetural exigida é que
Aa lógica de controle de fluxo das operações seja transferida para o cliente consumidor, mantendo o servidor como intermediador de dados.
Bo método POST seja mantido nas operações, desde que a estrutura da mensagem JSON contenha atributos descritivos suficientes para cada ação executada.
Cas operações passem a ser modeladas como recursos identificáveis por URI, utilizando corretamente os métodos HTTP conforme sua semântica e mantendo comunicação stateless.
Das operações permaneçam concentradas em um único endpoint, desde que o corpo da requisição contenha indicação explícita da ação desejada.
Ea API priorize padronização do JSON como principal requisito de integração, tratando a organização de recursos e a semântica HTTP como aspectos secundários.
Revelar gabarito e comentário▾
GabaritoC — as operações passem a ser modeladas como recursos identificáveis por URI, utilizando corretamente os métodos HTTP conforme sua semântica e mantendo comunicação stateless.
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): Adequação Arquitetural
Gabarito: letra C. Para evoluir ao estilo arquitetural REST, a integração deve modelar operações como recursos identificáveis por URI, utilizar os métodos HTTP conforme sua semântica (GET para consulta, POST para criação, PUT para atualização, DELETE para remoção) e manter comunicação stateless – exatamente o que a alternativa C descreve. As demais alternativas perpetuam o anti-padrão atual ou desrespeitam princípios fundamentais do REST.
A banca testa o conhecimento dos pilares do REST: recursos, métodos HTTP padronizados e ausência de estado (stateless). O cenário descreve uma API que usa POST para todas as operações com um campo acao no corpo – isso é típico de RPC (Remote Procedure Call), não REST. A correção exige que cada recurso tenha sua URI e que os verbos HTTP sejam usados corretamente.
Aspecto
REST (Correto)
Anti-padrão RPC (Cenário atual)
Alternativa C (Gabarito)
Modelagem
Recursos identificáveis por URI
Operações como funções (ex.: acao=cadastrar)
✅ Recursos identificáveis por URI
Métodos HTTP
GET, POST, PUT, DELETE conforme semântica
POST para todas as operações
✅ Métodos HTTP com semântica correta
Estado da comunicação
Stateless (cada requisição é independente)
Stateful (depende de sessão/contexto)
✅ Comunicação stateless
Endpoint
Múltiplos URIs (um por recurso)
Único endpoint (/api)
✅ Múltiplos URIs (implícito)
Identificação da ação
Pelo método HTTP + URI
Pelo campo acao no corpo JSON
✅ Pelo método HTTP + URI
REST (Representational State Transfer): Recursos (Identificáveis por URI, Navegáveis por hiperlinks (HATEOAS)); Métodos HTTP (GET: consulta, POST: criação, PUT: atualização, DELETE: remoção); Comunicação (Stateless (sem estado no servidor), Cada requisição autossuficiente)
Alternativa A – ❌ Incorreta
Afirma que a lógica de controle de fluxo deve ser transferida ao cliente, mantendo o servidor como intermediador. No REST, o servidor expõe recursos e o cliente navega entre eles por hiperlinks (HATEOAS), mas não há “transferência de fluxo” – o servidor não é mero intermediário, e sim provedor de recursos. O conceito está distorcido.
Alternativa B – ❌ Incorreta
Propõe manter o método POST para todas as operações, desde que o JSON contenha atributos descritivos. Isso viola o princípio de que cada método HTTP tem semântica própria. Uma API RESTful deve usar GET para consultas, POST para criação, PUT/PATCH para atualização, etc. A mera descrição no corpo não torna a API REST.
Alternativa C – ✅ Correta ⟵ GABARITO
Sintetiza corretamente os três requisitos essenciais do REST:
Recursos identificáveis por URI: cada entidade (cidadão, protocolo) é acessada por um URI único.
Métodos HTTP com semântica correta: GET para leitura, POST para criação, etc.
Comunicação stateless: cada requisição contém toda a informação necessária, sem dependência de estado no servidor.
Esses pontos são a base do estilo arquitetural REST, conforme definido por Fielding.
Alternativa D – ❌ Incorreta
Defende manter um único endpoint com indicação da ação no corpo – exatamente o anti-padrão atual. No REST, os endpoints representam recursos, não ações. A ação é expressa pelo método HTTP e pela URI (ex.: POST /cidadãos para criar, GET /cidadãos/{id} para consultar).
Alternativa E – ❌ Incorreta
Prioriza padronização do JSON como requisito principal, relegando a organização de recursos e semântica HTTP a aspectos secundários. No REST, a padronização do formato de dados é importante, mas a modelagem de recursos e o uso correto dos métodos HTTP são fundamentais e não podem ser secundários.
PEGA ESSA DICA!
Na prova, lembre-se dos três pilares do REST: URI para recursos, métodos HTTP corretos (GET, POST, PUT, DELETE) e stateless. Sempre que a questão falar em usar POST para tudo com campo acao, identifique como anti-padrão RPC. A alternativa que mencionar múltiplos endpoints e verbos adequados é a correta.