José é o arquiteto de software em uma equipe de desenvolvimento de sistemas e recebeu a demanda de projetar serviços que estarão disponíveis na API RESTful a ser utilizada por três aplicações distintas. Considerando as restrições de uma API RESTful, José deve garantir que:
- A)as respostas geradas pela API RESTful sejam formatadas em XML;
Errada: REST nao obriga resposta em XML, pois pode usar JSON, XML e outros formatos conforme negociacao de conteudo.
- B)o uso de REST envelopes seja o recurso para troca de mensagens entre as aplicações e a API RESTful;
Errada: REST nao exige uso de envelopes de mensagem; isso e mais associado a outros estilos e protocolos, nao ao REST puro.
- C)requisições à API RESTful sejam precedidas de um acesso via Single Sign-On (SSO) válido;
Errada: SSO pode ser usado na seguranca da aplicacao, mas nao e restricao da arquitetura REST.
- D)cada uma das aplicações faça requisições à API RESTful por meio de um URI (Uniform Resource Identifier) próprio;
Errada: o conceito de URI propria vale para identificar recursos, nao para cada aplicacao ter um URI proprio como requisito de REST.
- E)cada requisição das aplicações para a API RESTful contenha toda a informação necessária para o processamento da resposta, sem considerar o estado da sessão.
Certa: REST e stateless, entao cada requisicao deve trazer tudo o que o servidor precisa para processa-la, sem depender de estado de sessao.
Gabarito: E
Em REST, uma regra central é a statelessness, ou seja, o servidor nao deve depender de informacoes guardadas de uma requisicao anterior para processar a proxima. Cada chamada precisa levar o suficiente para ser entendida sozinha. Em outras palavras: a API nao pode “ficar lembrando” da conversa como se estivesse em um bate-papo de aplicativo de mensagem. Isso melhora escalabilidade, simplicidade e confiabilidade, porque qualquer servidor pode atender a requisicao sem depender de um estado escondido em sessao. Na pratica, autenticação, parametros, identificadores do recurso e demais dados necessarios devem acompanhar cada request. Esse e um dos principios classicos de REST descritos por Roy Fielding em sua tese de doutorado, que fundamenta a arquitetura REST. Por isso, o gabarito e a letra E: a requisicao deve conter toda a informacao necessaria para o processamento da resposta, sem considerar o estado da sessao. A ideia e evitar dependencia de contexto armazenado no servidor, mantendo a comunicacao entre cliente e API independente a cada chamada. As demais alternativas trazem elementos que nao sao exigencias de REST, como XML obrigatorio, envelopes de mensagem ou SSO como regra da arquitetura. REST pode ate coexistir com esses recursos em alguns projetos, mas eles nao sao restricoes do estilo arquitetural.