Revisando API’s RESTFul usando questões do CEBRASPE

Fala, meus consagrados! Beleza?

Revisaremos agora sobre API’s RESTFul e suas principais características, focando as questões do CEBRASPE. Simbora!

Métodos de requisições HTTP para manipulação dos recursos

[CESPE/CEBRASPE 2025 EMBRAPA – Pesquisador – Área: Gestão da Informação – Subárea: Engenharia de Dados] Considerando os métodos HTTP utilizados em APIs REST, julgue o próximo item, a respeito de integração de dados e mecanismos de interoperabilidade. 

O método POST é seguro e idempotente, pois a execução de múltiplas requisições resulta no mesmo estado final dos dados.

Comentários:

O método POST criar um novo recurso e é utilizado para submeter uma entidade a um recurso específico, frequentemente causando uma mudança no estado do recurso ou efeitos colaterais no servidor.

Temos três tipos de métodos do protocolo HTTP:

• Seguro (safe methods);
• Idempotente; e
• Cacheável.

Um método seguro não altera o estado do servidor, ou seja, leva a uma operação de somente leitura. São métodos seguros:

• GET;
• HEAD; e
• OPTIONS.

Um método idempotente é um método em que uma requisição idêntica pode ser feita uma ou mais vezes, em sequência, com o mesmo efeito, enquanto deixa o servidor no mesmo estado. Ou seja, não deveria possuir nenhum efeito colateral, exceto para manter estatísticas.

São métodos idempotentes:

• GET;
• HEAD;
• OPTIONS;
• PUT;
• DELETE; e
• TRACE.

Sobre métodos cacheáveis, uma resposta cacheável é uma resposta HTTP que pode ser armazenada em cache, para ser recuperada e usada posteriormente, salvando uma nova solicitação no servidor. São métodos cacheáveis:

• GET;
• HEAD; e
• POST (somente se houver informações atualizadas).

Com essa revisão, POST não é seguro nem idempotente, mas cacheável.

Gabarito: ERRADO.

[CESPE/CEBRASPE 2025 EMBRAPA – Pesquisador – Área: Gestão da Informação – Subárea: Engenharia de Dados] Considerando os métodos HTTP utilizados em APIs REST, julgue o próximo item, a respeito de integração de dados e mecanismos de interoperabilidade. 

Os métodos GET e HEAD são considerados seguros, pois sua execução não deve modificar os dados armazenados no servidor, embora possa gerar efeitos colaterais indiretos, como registros de logs.

Comentários:

Como visto acima, os métodos GET e HEAD são classificados como métodos seguros. Isso significa que sua semântica não deve causar alteração no estado dos recursos do servidor, ou seja, não devem modificar dados, apenas realizar operações de leitura.

Por que são considerados seguros?

• GET: recupera representações de recursos; e
• HEAD: igual ao GET, mas retorna apenas cabeçalhos, sem corpo na resposta.

Em ambos os casos:

• Não devem criar, atualizar ou deletar dados; e
• Não devem modificar o estado do recurso no servidor.

Eles Podem gerar efeitos colaterais indiretos, que são possíveis e esperados, como:

• Registro de logs;
• Contagem de visitas;
• Cache warming;
• Rastreamento analítico.

Esses efeitos não caracterizam insegurança, pois não alteram o estado do recurso em si. São considerados efeitos colaterais não observáveis ou não relevantes para o estado do recurso, conforme as especificações HTTP.

Gabarito: CERTO.

Suporte a representações

[CESPE/CEBRASPE 2024 CAU/BR – Analista de Infraestrutura de Tecnologia da Informação] Acerca da arquitetura de sistemas de N camadas e das APIs, julgue o próximo item.

Uma API REST utiliza somente o formato XML para representar os recursos e as respostas do servidor.  

Comentários:

Uma API REST não utiliza somente XML. Na verdade, REST é independente de formato: qualquer representação pode ser usada, desde que o cliente e o servidor a entendam.

REST pode usar diversos formatos, como:

• JSON (o mais comum atualmente);
• XML;
• YAML;
• CSV;
• HTML;
• Texto puro;
• Imagens;
• PDF;
• Binários;
• Entre outros.

A negociação de conteúdo ocorre por meio dos cabeçalhos HTTP:

• Accept: o cliente informa quais formatos aceita; e
• Content-Type: o servidor informa o formato da resposta.

REST não impõe um formato específico. XML foi comum no início, mas não é obrigatório. JSON é hoje o padrão de fato para APIs REST modernas.

Gabarito: ERRADO.

Princípios/restrições e outros tópicos

[CESPE/CEBRASPE 2025 PCDF – Gestor de Apoio as Atividades Policiais Civis – Especialidade:  Analista de Informática: Desenvolvimento de Sistemas] Julgue o item a seguir, relativo a tecnologias e padrões para o desenvolvimento web, intercâmbio de dados e comunicação entre sistemas.

O princípio cacheable do padrão REST estabelece que as respostas às solicitações são gerenciadas pelo servidor, que decide acerca do armazenamento em cache dos dados, otimizando o desempenho do cliente.

Comentários:

O princípio cacheable do REST não afirma que o servidor decide sozinho sobre o armazenamento em cache. O que o princípio estabelece é que todas as respostas de uma API REST devem ser explicitamente rotuladas como cacheáveis ou não cacheáveis, permitindo que clientes, proxies ou intermediários possam armazenar tais respostas em cache quando apropriado.

No princípio cacheable, cada resposta deve indicar, por meio de cabeçalhos HTTP (como Cache-Control, Expires, ETag, Last-Modified), se pode ou não ser armazenada em cache. Isso permite que clientes, proxies e gateways decidam guardar e reutilizar respostas para otimizar desempenho.

Ponto-chave:

• O servidor informa a política de cache, mas não gerencia sozinho o armazenamento; e
• Quem armazena é o cliente ou os intermediários.

Gabarito: ERRADO.

Espero que tenham gostado! 

Forte abraço e até a próxima jornada!

_________________________

Professor Rogerão Araújo