Questão 157951

• Banca: CESGRANRIO
• Órgão: TJ-RO
• Ano: 2008
• Provas: CESGRANRIO - 2008 - TJ-RO - Agente Judiciário - Analista de Sistemas (Microinformática)
• Disciplina: Arquitetura de Software
• Assuntos: WebServices

Diversos frameworks e APIs, incluindo a Java API for XML Web Services (JAX-WS), provêem suporte para uma abordagem arquitetural chamada REST (Representational State Transfer) para a criação de web services simples, que utilizam apenas o protocolo HTTP, dispensando uma camada de mensagens como o SOAP. Para tanto, cada serviço é disponibilizado na forma de um recurso associado a uma URL e os métodos do protocolo HTTP são utilizados para "comandar" ações de inclusão, atualização, exclusão e consulta de dados. Vista sob este prisma, a World Wide Web em si é um exemplo da abordagem arquitetural REST.
NÃO corresponde a um método previsto no protocolo HTTP/1.1:

• A. DELETE
  
• B. GET
  
• C. INSERT
  
• D. POST
  
• E. PUT

Gabarito: C

Comentários

• GET: O método GET significa recuperar qualquer informação (na forma de uma entidade) é identificado pelo Request-URI. Se o Request-URI se refere a um processo de produção de dados, é que os dados produzidos serão devolvidos como a entidade na resposta e não o texto fonte do processo, a menos que o texto passa a ser a saída do processo.
  
  POST: O método POST é usado para solicitar que o servidor de origem aceitar a entidade fechada no pedido como um novo subordinado do recurso identificado pelo Request-URI na Request-Line. (é o famoso "postar" na redes sociais hehehe)
  
  PUT: O PUT pedidos método que a entidade fechada ser armazenados sob fornecido Request-URI. Se o Request-URI se refere a um recurso já existente, a entidade fechada deve ser considerada como uma versão modificada do que residem em um servidor de origem. Se o Request-URI não aponta para um recurso existente, e que URI é capaz de ser definido como um novo recurso por parte do agente usuário solicitante, o servidor de origem pode criar o recurso com que a URI. Se um novo recurso é criado, o servidor de origem deve informar o agente do usuário através do 201 resposta (Criado). Se um recurso existente é modificado, ou os códigos de resposta 200 (OK) ou 204 (No Content) devem ser enviados para indicar a conclusão do pedido. Se o recurso não pôde ser criado ou modificado com o Request-URI, uma resposta de erro apropriada deve ser dada de que reflete a natureza do problema. O destinatário da entidade não deve ignorar qualquer Content-* (por exemplo, Content-Range) cabeçalhos que não entendem ou implementar e deve retornar um 501 resposta (não implementado), em tais casos.
  
  DELETE: DELETE pedidos método que o servidor de origem excluir o recurso identificado pelo Request-URI. Este método pode ser substituído por intervenção humana (ou outros meios) no servidor de origem. O cliente não pode ser garantido que a operação foi realizada, mesmo se o código de status retornado do servidor de origem indica que a ação foi concluída com êxito. No entanto, o servidor não deve indicar o sucesso a menos que, no momento em que a resposta é dada, que pretende excluir o recurso ou movê-lo para um local inacessível.
  
• Wiki no google translator ... :)

• Não deveria ser JAX-RS?