Pensando em uma implementação comum da API REST, assinale a opção que indica o principal princípio associado ao seu estilo arquitetural.
- A)Comunicação bidirecional entre clientes e servidores.
Errada, porque REST não se define por comunicação bidirecional entre cliente e servidor, e sim pelo uso de recursos e verbos HTTP padronizados.
- B)Transferência de representações de recursos por meio de operações padrão (como GET, POST, PUT e DELETE).
Certa, pois REST se apoia na transferência de representações de recursos usando operações padrão do HTTP, como GET, POST, PUT e DELETE.
- C)Transferência direta somente de objetos Javascript entre clientes e servidores.
Errada, porque REST não é limitado à transferência de objetos JavaScript; normalmente trabalha com representações como JSON, XML ou outros formatos.
- D)Utilização de mensagens SOAP para comunicação entre sistemas.
Errada, porque SOAP é outra tecnologia de web service, com envelope XML e regras próprias, não o estilo arquitetural REST.
- E)Utilização de um modelo de solicitação com estado.
Errada, porque REST preza por requisições stateless, isto é, sem manter estado entre chamadas.
Gabarito: B
A API REST costuma ser cobrada como um estilo arquitetural, e não como um protocolo fechado. A ideia central é simples: você trabalha com recursos, identificados por URLs, e os manipula por meio de operações padronizadas do HTTP, como GET, POST, PUT e DELETE. Em outras palavras, você não "manda uma ação mágica" para o servidor; você acessa uma representação do recurso e a altera ou consulta conforme o verbo HTTP usado. Esse é o coração do REST: transferência de representações de recursos. O cliente pede uma representação, e o servidor devolve algo como JSON ou XML, dependendo da implementação. Por isso, a alternativa correta é a B, porque ela descreve exatamente esse modelo de uso dos verbos HTTP sobre recursos. Em prova, quando aparecer REST, pense logo em recursos, representações e verbos HTTP padronizados. As outras opções misturam REST com ideias de outros estilos ou tecnologias. SOAP, por exemplo, é um protocolo diferente, mais ligado a web services baseados em envelope XML. Já estado na solicitação vai na direção contrária do princípio REST de ser stateless, ou seja, sem manter estado de sessão entre requisições. A FGV gosta bastante dessa troca de conceitos, então vale ficar atento.