SoapUI RESTful - Métodos HTTP

Os métodos HTTP mais comumente usados ​​são POST, GET, PUT, PATCH e DELETE. Eles correspondem às operações de criação, leitura, atualização e exclusão (ou CRUD), respectivamente. Existem vários outros métodos também, mas são utilizados com menos frequência. Entre esses métodos, OPTIONS e HEAD são usados ​​com mais frequência do que outros.

POSTAR

O método POST é usado para criar novos recursos. É usado para criar recursos subordinados. Ou seja, subordinado a algum outro recurso (por exemplo, pai).

Em outras palavras, ao criar um novo recurso, o POST para o pai e o serviço se encarrega de associar o novo recurso ao pai, atribuindo um ID (novo URI de recurso), etc.

Na criação bem-sucedida, retorne o status HTTP 201, retornando um cabeçalho de localização com um link para o recurso recém-criado com os status 201 HTTP.

O POST não é seguro nem idempotente. Portanto, é recomendado para solicitações de recursos não idempotentes.

Fazer duas solicitações POST idênticas resultará em dois recursos contendo as mesmas informações. Às vezes, ele lança uma mensagem de erro com base no tipo de serviço definido.

PEGUE

O método HTTP GET é usado para ler ou recuperar uma representação de um recurso. Em uma resposta bem-sucedida, GET retorna uma representação em XML ou JSON e um código de resposta HTTP de 200 (OK). Em um caso de erro, ele geralmente retorna um 404 (NÃO ENCONTRADO) ou 400 (PEDIDO RUIM).

De acordo com o projeto da especificação HTTP, as solicitações GET (junto com HEAD) são usadas apenas para ler dados e não alterá-los. Portanto, GET é considerado seguro.

GET pode ser chamado sem risco de modificação ou corrupção de dados - chamá-lo uma vez tem o mesmo efeito que chamá-lo 10 vezes. Além disso, GET é idempotente, o que significa que fazer várias solicitações idênticas leva ao mesmo resultado de uma única solicitação.

É recomendado não expor operações inseguras via GET - ele nunca deve modificar quaisquer recursos no servidor.

COLOCAR

PUT é usado para atualizar os recursos existentes. PUT é usado como um URI de recurso conhecido com o corpo da solicitação que contém a representação atualizada do recurso original.

PUT também pode ser usado para criar um recurso em que o ID do recurso é escolhido pelo cliente em vez de pelo servidor. Em outras palavras, se PUT for usado como um URI que contém o valor de um ID de recurso inexistente.

POST é usado para criar novos recursos e fornecer o ID definido pelo cliente na representação do corpo. Na atualização bem-sucedida, ele retorna 200 (ou 204, se não retornar nenhum conteúdo no corpo) de um PUT.

Se PUT for usado para a criação, ele retornará o status HTTP 201 na criação bem-sucedida. Um corpo na resposta é opcional.

PUT não é uma operação segura, pois modifica (ou cria) o estado do servidor, porém é idempotente. Se o usuário criar ou atualizar um recurso usando PUT e depois fizer a mesma chamada novamente, o recurso ainda estará lá e terá o mesmo estado da primeira chamada.

Recomenda-se manter as solicitações PUT idempotentes. É altamente recomendável usar POST para solicitações não idempotentes.

FRAGMENTO

PATCH é usado para modificar recursos. A solicitação PATCH precisa conter apenas as mudanças no recurso, não o recurso completo. Ele se parece com PUT, mas o corpo contém um conjunto de instruções que descrevem como um recurso atualmente residente no servidor deve ser modificado para produzir uma nova versão.

Isso significa que o corpo PATCH não deve ser apenas uma parte modificada do recurso, mas deve estar em algum tipo de linguagem de patch, como JSON Patch ou XML Patch.

PATCH não é seguro nem idempotente. Uma solicitação PATCH pode ser emitida de forma a ser idempotente, o que também ajuda a evitar resultados ruins de colisões entre duas solicitações PATCH no mesmo recurso em um período de tempo semelhante.

Colisões de várias solicitações PATCH podem ser mais perigosas do que colisões PUT, pois alguns formatos de patch precisam operar a partir de um ponto de base conhecido, caso contrário, eles corromperão o recurso.

Os clientes que usam esse tipo de aplicativo de patch devem usar uma solicitação condicional de forma que a solicitação falhe, se o recurso tiver sido atualizado, desde a última vez que o cliente acessou o recurso.

EXCLUIR

DELETE é usado para excluir um recurso identificado por um URI. Na exclusão bem-sucedida, ele retorna o status HTTP 200 (OK) junto com um corpo de resposta, representação do item excluído. Caso contrário, ele retorna o status HTTP 204 (SEM CONTEÚDO) sem corpo de resposta.

Em outras palavras, um status 204 sem corpo ou a resposta de estilo JSEND e status HTTP 200 são as respostas recomendadas.

Em termos de especificações HTTP, as operações DELETE são idempotentes. Se o usuário excluir um recurso, ele será removido. Chamar DELETE repetidamente no mesmo recurso acaba com o mesmo resultado: o recurso acabou.

Chamar DELETE em um recurso uma segunda vez geralmente retornará um 404 (NÃO ENCONTRADO), pois ele já foi removido e, portanto, não pode mais ser localizado. Isso torna as operações DELETE não mais idempotentes; no entanto, o estado final do recurso é o mesmo. Retornar um 404 é aceitável e se comunica com precisão com o status da chamada.