Pular para o conteúdo principal

Questão de Arquitetura de Software — Arquitetura Cliente-Servidor — FCC 2024

Arquitetura de SoftwareArquitetura Cliente-Servidor
Código
fc071912
Banca
FCC
Órgão
TRT - 20ª REGIÃO (SE)
Ano
2024
Nível
Superior
Cargo
Analista Judiciário - Área Apoio Especializado - Especialidade Tecnologia da Informação
De acordo com a Plataforma Digital do Poder Judiciário - PDPJ-Br, para que uma API seja considerada do tipo RESTful, ela precisa estar em conformidade, dentre outros, com o seguinte critério:
  1. Ater uma arquitetura cliente/servidor formada por clientes, servidores e recursos, com solicitações gerenciadas por meio de HTTP.
  2. Bpossuir o sistema de comunicação entre os componentes por meio de troca de mensagens REST-Enq, fazendo uso de um Message Broker. No caso da PDPJ, utiliza-se a solução BrokerMQ.
  3. Cter uma interface ampla e livre entre os componentes desde que sejam usados os parâmetros RESTful Config para que as informações sejam transferidas em um formato padronizado.
  4. Dter autenticação por meio de uma solução de RFPJ Sign On baseada no protocolo PDPJ Auth2.
  5. Epermitir que as APIs registradas sejam acessíveis por meio do Gateway RESTful-API-Sync.
Revelar gabarito e comentário

GabaritoA — ter uma arquitetura cliente/servidor formada por clientes, servidores e recursos, com solicitações gerenciadas por meio de HTTP.

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”.

APIs RESTful e a PDPJ-Br

Gabarito: letra A. O estilo arquitetural REST (Representational State Transfer) exige uma arquitetura cliente-servidor onde clientes, servidores e recursos são identificados por URIs e as solicitações são gerenciadas por HTTP, conforme os princípios definidos por Roy Fielding. A alternativa A descreve exatamente esse critério.

A banca testa se o candidato conhece os fundamentos do REST, distinguindo-os de tecnologias específicas ou termos inventados que não fazem parte do modelo.

Alternativa A — ✅ Correta ⟵ GABARITO

Afirma que a API deve ter arquitetura cliente/servidor com clientes, servidores e recursos, com solicitações via HTTP. Isso é correto: REST utiliza HTTP como protocolo de comunicação, define recursos, e a separação cliente-servidor é um dos princípios fundamentais (interface uniforme, stateless, cache, etc.).

Alternativa B — ❌ Incorreta

Menciona "sistema de comunicação por troca de mensagens REST-Enq" e "Message Broker" com "BrokerMQ". REST não exige um message broker; a comunicação é direta entre cliente e servidor, sem intermediários assíncronos. O termo "REST-Enq" não é padrão. Portanto, a alternativa introduz elementos alheios ao REST.

Alternativa C — ❌ Incorreta

Propõe "interface ampla e livre" e "parâmetros RESTful Config". REST possui uma interface uniforme e restrita (métodos HTTP, URIs, códigos de status), não "ampla e livre". "RESTful Config" não é uma especificação real. A alternativa confunde flexibilidade com falta de padronização.

Alternativa D — ❌ Incorreta

Cita "RFPJ Sign On" e "PDPJ Auth2", que são termos fictícios ou específicos da PDPJ-Br, não critérios REST. REST não define mecanismo de autenticação; isso é responsabilidade da aplicação. A alternativa tenta associar indevidamente tecnologias de single sign-on ao estilo REST.

Alternativa E — ❌ Incorreta

Fala em "Gateway RESTful-API-Sync". REST não exige gateway; a comunicação pode ser direta ou via proxy, mas não é um critério do estilo. "API-Sync" sugere comunicação síncrona, mas REST é stateless e pode ser síncrono ou assíncrono, não sendo isso um requisito definidor.

Conclusão: Apenas a alternativa A descreve corretamente um critério para APIs RESTful, alinhado com os princípios do estilo. Gabarito: letra A.

Link permanente: /questoes/fc071912