REST e SOAP são duas abordagens diferentes que definem como os clientes acessam determinado serviço ...

Alternativa (B) - Há um comportamento previsível pelo fato de se utilizar operações nativas do protocolo HTTP, como os métodos GET, POST, PUT e DELETE.

Introdução

A questão aborda o tema das arquiteturas baseadas em serviço, especificamente a abordagem REST (Representational State Transfer), que é um estilo arquitetural amplamente utilizado para construir APIs web. Compreender as características de REST é fundamental para o desenvolvimento de aplicações distribuídas e integração de sistemas na internet.

Desenvolvimento

REST é um estilo arquitetural que define um conjunto de princípios e restrições para a criação de serviços web escaláveis e eficientes. Diferentemente de SOAP, que é um protocolo com regras mais rígidas, REST é mais flexível e se baseia na infraestrutura existente da web, utilizando o protocolo HTTP de forma padronizada.

Os princípios chave do REST incluem:

• Cliente-Servidor: Separação das preocupações do cliente e do servidor.
• Sem Estado (Stateless): Cada requisição do cliente para o servidor deve conter todas as informações necessárias para entender a requisição, pois o servidor não armazena nenhum contexto do cliente entre as requisições.
• Cacheable: As respostas devem ser explicitamente ou implicitamente definidas como cacheáveis ou não cacheáveis para prevenir que clientes reutilizem dados obsoletos.
• Interface Uniforme: É a restrição central do REST. Simplifica a arquitetura do sistema, tornando-o mais fácil de ser compreendido e evoluído. Esta interface uniforme é alcançada através de:
  • Identificação de recursos: Cada recurso é identificado por um URI (Uniform Resource Identifier).
  • Manipulação de recursos através de representações: O cliente interage com o recurso por meio de uma representação (e.g., JSON, XML) que ele recebe do servidor.
  • Mensagens auto-descritivas: As mensagens contêm informações suficientes para descrever como processar a mensagem.
  • Hipermídia como motor do estado da aplicação (HATEOAS): O cliente deve ser capaz de descobrir as ações disponíveis e os recursos relacionados através dos links fornecidos nas representações.
• Sistema em Camadas: Permite que proxies, gateways e outros componentes de infraestrutura sejam inseridos entre o cliente e o servidor.
• Código Sob Demanda (Code-On-Demand - opcional): Permite que o servidor estenda a funcionalidade do cliente enviando código executável.

Um aspecto fundamental da interface uniforme do REST é o uso dos métodos HTTP padrão (GET, POST, PUT, DELETE, PATCH, OPTIONS, HEAD) de forma semântica, para realizar operações CRUD (Create, Read, Update, Delete) sobre os recursos.

Análise

Vamos analisar cada alternativa:

• (A) Como se trata de um protocolo, há regras integradas que aumentam sua complexidade e sobrecarga, desacelerando o tempo de carregamento das páginas.

  • Incorreta. REST não é um protocolo, mas sim um estilo arquitetural. Ele utiliza o protocolo HTTP, que é eficiente e amplamente otimizado. Ao contrário de protocolos mais pesados como SOAP, que pode envolver uma sobrecarga significativa devido ao seu XML extenso e regras específicas, REST tende a ser mais leve e performático justamente por se apoiar na simplicidade do HTTP.

• (B) Há um comportamento previsível pelo fato de se utilizar operações nativas do protocolo HTTP, como os métodos GET, POST, PUT e DELETE.

  • Correta. Esta é uma característica fundamental do REST. Ao mapear as operações CRUD diretamente para os métodos HTTP (GET para leitura, POST para criação, PUT para atualização completa/substituição, DELETE para exclusão, PATCH para atualização parcial), a API se torna intuitiva e previsível. Os desenvolvedores já estão familiarizados com a semântica desses métodos HTTP, o que facilita a construção e o consumo de APIs RESTful.

• (C) É obrigatório o uso da linguagem XML.

  • Incorreta. REST é agnóstico ao formato dos dados. Embora XML tenha sido historicamente usado, JSON (JavaScript Object Notation) é o formato mais comum e preferido atualmente devido à sua leveza e facilidade de manipulação em JavaScript. Outros formatos como plain text, HTML, ou YAML também podem ser utilizados.

• (D) Tem o protocolo TCP e faz uso de fibras ópticas para transportar as mensagens trocadas entre as aplicações.

  • Incorreta. Esta alternativa descreve tecnologias de rede de baixo nível. O TCP (Transmission Control Protocol) é um protocolo da camada de transporte que o HTTP (e, por extensão, o REST) utiliza para garantir a entrega confiável dos dados. Fibras ópticas são um meio físico de transmissão. Embora sejam componentes essenciais da infraestrutura da internet, eles não são características da abordagem REST em si, que opera em um nível de abstração muito mais alto (camada de aplicação), definindo como os clientes e servidores interagem com recursos, não como os bits são fisicamente transportados.

• (E) É possível a duplicação de mensagens, o que diminui o risco de que elas se percam.

  • Incorreta. A duplicação de mensagens não é um objetivo ou uma característica desejável do REST. O protocolo TCP, utilizado por HTTP, já garante a entrega confiável e a ausência de duplicação de pacotes na camada de transporte. Em termos de operações de aplicação, métodos como PUT e DELETE são projetados para serem idempotentes, o que significa que a execução de uma operação várias vezes produz o mesmo resultado que executá-la uma única vez. Isso permite que os clientes retransmitam requisições com segurança em caso de falha de rede ou timeout, sem que a duplicação da operação cause efeitos colaterais indesejados no servidor. Não é sobre "diminuir o risco de perda" através de duplicação proposital, mas sim sobre a robustez contra retransmissões.

Conclusão

A abordagem REST se destaca por sua simplicidade e por alavancar os padrões existentes da web. A utilização semântica dos métodos HTTP (GET, POST, PUT, DELETE) para interagir com recursos confere às APIs RESTful uma previsibilidade e facilidade de uso que são pilares de sua popularidade e eficácia no desenvolvimento de sistemas distribuídos modernos.

Alternativa (B).