Observe a seguinte requisição em Hypertext Transfer Protocol (HTTP) feita a uma Application Programming Interface (API) RESTful: PUT http://webservice.tjapp/recursos/1 A respectiva resposta HTTP da API RESTful apresentou o código de status 204. Os dados apresentados acima indicam que a API RESTful processou a solicitação de:
- A)obtenção de um recurso de forma bem-sucedida;
Errada: GET é o método mais associado à obtenção de recursos, não o PUT, e o código 204 não indica simples leitura.
- B)atualização de um recurso de forma malsucedida;
Errada: a resposta 204 indica sucesso, não falha, então não faz sentido falar em atualização malsucedida.
- C)criação de um novo recurso de forma malsucedida;
Errada: criação de recurso costuma ser associada a POST, e 204 não sugere tentativa frustrada de criação.
- D)atualização de um recurso de forma bem-sucedida;
Certa: PUT em um recurso específico indica atualização, e o 204 mostra que a solicitação foi processada com sucesso sem corpo na resposta.
- E)criação de um novo recurso de forma bem-sucedida.
Errada: criação bem-sucedida normalmente ocorre com POST, não com PUT, especialmente quando a URI já aponta para um recurso específico.
Gabarito: D
Em HTTP, o verbo usado na requisição diz muito sobre a intenção da operação. O PUT é o método típico para atualizar um recurso identificado por uma URI específica, enviando a representação nova ou completa daquele recurso. Na prática, pense assim: se o recurso já existe em /recursos/1 e você manda um PUT para esse endereço, a lógica é substituir ou atualizar o que estava lá. O código de status 204 significa No Content, isto é, a solicitação foi processada com sucesso, mas a resposta não traz corpo. Em APIs RESTful, isso é bem comum quando a atualização acontece sem necessidade de devolver o conteúdo atualizado. Ou seja: o servidor aceitou e executou a mudança, só não devolveu uma mensagem gigante para enfeitar a resposta. Por isso, o conjunto PUT + 204 aponta para atualização bem-sucedida de um recurso. Esse entendimento está alinhado com a semântica padronizada do HTTP, definida pelo IETF na RFC 7231 e, mais recentemente, na RFC 9110, que tratam PUT como método de substituição/atualização e 204 como resposta de sucesso sem corpo. Então, o gabarito D está correto porque a API recebeu uma requisição de atualização em um recurso específico e respondeu com sucesso, apenas sem conteúdo na resposta.