REST (Representational State Transfer) — Restrições arquiteturais
Gabarito: letra E. A restrição de statelessness (ausência de estado) do estilo REST determina que cada requisição do cliente ao servidor deve conter toda a informação necessária para ser compreendida, não podendo o servidor armazenar contexto de sessão entre requisições. A alternativa E descreve exatamente essa violação: armazenar informações de contexto ou estado de sessão no servidor entre requisições. As demais alternativas estão em conformidade com as restrições do REST.
Conteúdo de Apoio:
"As webs service compatíveis com REST permitem que os sistemas solicitantes acessem e manipulem representações textuais de recursos da Web usando um conjunto uniforme e predefinido de operações sem estado." (grifo nosso)
Alternativa A — ❌ Incorreta (não viola)
O uso de XML (ou JSON) é apenas uma questão de formato de representação. REST não impõe um formato específico; tanto XML quanto JSON são perfeitamente aceitáveis, desde que o cliente e servidor concordem com a representação (negociação de conteúdo).
Alternativa B — ❌ Incorreta (não viola)
O cache de respostas é uma restrição explícita do REST (cacheable). Respostas podem ser marcadas como cacheáveis ou não, e clientes e intermediários podem realizar cache para melhorar desempenho. Isso está de acordo com o estilo.
Alternativa C — ❌ Incorreta (não viola)
Embora o HTTP seja o protocolo mais comum em implementações RESTful, o estilo arquitetural REST não exige exclusivamente HTTP. Outros protocolos podem ser utilizados, desde que respeitem as restrições (como interface uniforme, stateless, etc.). A alternativa não configura violação.
Alternativa D — ❌ Incorreta (não viola)
A exclusão de um recurso (operação DELETE) é uma das operações padrão permitidas pela interface uniforme do REST. O cliente pode solicitar a exclusão de um recurso no servidor, o que está em conformidade com o modelo de manipulação de recursos.
Alternativa E — ✅ Correta (viola) ⟵ GABARITO
O armazenamento de estado de sessão no servidor entre requisições quebra a restrição fundamental de statelessness do REST. Cada requisição deve ser independente e conter todas as informações necessárias para seu processamento. O servidor não deve manter contexto do cliente entre requisições, garantindo escalabilidade e simplicidade. A alternativa descreve exatamente essa violação.
Gabarito: letra E.