REST (Representational State Transfer) é um estilo de arquitetura baseado em um conjunto de princípios que descrevem como os recursos em rede são definidos e endereçados. São consideradas características do REST, EXCETO:
- A)Armazena informações de estado entre troca de mensagens.
Errada, porque REST é stateless e não deve armazenar estado entre as trocas de mensagens.
- B)O identificador de recurso é o caminho URI (ou URL) onde o serviço se encontra.
Certa, pois o recurso REST é identificado por uma URI ou URL.
- C)Serviços compartilham um contrato uniforme e este contrato é definido por meio de métodos HTTP.
Certa, já que o REST usa um contrato uniforme com verbos HTTP padronizados.
- D)Tem baixa sobrecarga de comunicação em relação ao SOAP por receber e transmitir mensagens no formato JSON.
Certa, porque REST costuma ter menor sobrecarga que SOAP e frequentemente usa JSON.
- E)Trabalha com o conceito de contrato uniforme (uniform contract), não sendo necessário definir contratos individuais para cada Web service.
Certa, pois o REST trabalha com contrato uniforme e evita contratos individuais por serviço.
Gabarito: A
REST é um estilo de arquitetura para serviços na web que gira em torno de recursos, identificados por URIs, e manipulados por verbos HTTP como GET, POST, PUT e DELETE. A lógica do REST é manter a comunicação simples, padronizada e sem excesso de cerimônia, o que normalmente reduz a sobrecarga em comparação com abordagens mais pesadas, como SOAP. Um ponto central do REST é a ideia de stateless, ou seja, cada requisição deve conter todas as informações necessárias para ser processada. O servidor não deve guardar o estado da sessão entre uma chamada e outra. Isso ajuda na escalabilidade e na simplicidade do sistema. Por isso, a alternativa A está errada e é a exceção da questão: ela afirma que o REST armazena informações de estado entre trocas de mensagens, mas isso contraria diretamente o princípio de ausência de estado. Na doutrina clássica sobre REST, como a de Roy Fielding, a comunicação deve ser stateless. As demais alternativas estão alinhadas com características conhecidas do REST: uso de URI para identificar recursos, contrato uniforme baseado em métodos HTTP, menor sobrecarga e uso comum de JSON, além da padronização que evita contratos individuais para cada serviço.