7 métodos HTTP todo desenvolvedor web deve conhecer e como testá-los

Já se perguntou qual a diferença entre GET e POSTpedidos, ou quando usar PUT? Não estás sozinho. Tendo uma compreensão basic dos diferentes métodos HTTP, ou verbos, um APIsupports é um conhecimento útil ao explorar e testar APIs.

neste post, vou discutir como cada método HTTP é usado e como incorporá-los em seu teste de API.

HTTP Métodos

• GET
• POST
• PUT
• HEAD
• DELETE
• PATCH
• OPTIONS

GET

GET pedidos são os mais comuns e mais utilizados métodos de APIs andwebsites. Simplificando, o método GET é usado para retirar dados de aserver no recurso especificado. Por exemplo, digamos que você tem uma APIwith a /users endpoint. Fazer um pedido para chegar a esse ponto final deve reverter uma lista de todos os utilizadores disponíveis.

Uma vez que um pedido GET está apenas solicitando dados e não modificando quaisquer recursos, ele considera um método seguro e idempotente.

o Teste de uma API com solicitações GET

Quando você estiver criando testes para uma API, o GET método provavelmente bethe mais freqüente tipo de solicitação feita pelos consumidores do serviço, soit importante verificar todos os conhecidos de ponto de extremidade com uma solicitação GET.

a um nível básico, estas coisas devem ser validadas:

• verifique se um pedido de obtenção válido devolve a 200 código de Estado.
• certifique-se de que um pedido de obtenção de um recurso específico devolve os dados corretos. Por exemplo, GET /users devolve uma lista de utilizadores.

GET é muitas vezes o método padrão em clientes HTTP, então a criação de testes para esses recursos deve ser simples com qualquer ferramenta que você escolher.

POST

em serviços web, POST pedidos são usados para enviar dados para o Apiservador para criar ou udpate um recurso. Os dados enviados para o servidor são acompanhados noquest corpo do pedido HTTP.

O exemplo mais simples é um formulário de contato em um site. Quando você preenche as entradas em um formulário e carrega em enviar, os dados são colocados no corpo de resposta do pedido e enviados para o servidor. Este talvez JSON, XML,ou parâmetros de consulta (há uma abundância de outros formatos, mas estes são os mais comuns).

vale a pena notar que umPOST pedido não é idempotente. Itmutates data on the backend server( by creating or updating aresource), as opposed to a GET request which does not change anydata. Aqui está uma grande explicação de idempotência.

Testing an API with POST requests

the second most common HTTP method you’ll encounter in your API testsis POST. Como mencionado acima,POST pedidos são usados para enviar dados para o servidor de API e criar ou atualizar um recurso. SincePOST solicita modificar os dados, é importante ter testes API para todos os seus métodos POST.

Aqui estão algumas dicas para testar pedidos de POST:

• crie um recurso com um POST requisição e assegure que um 200 código de Estado seja devolvido.
• Em seguida, faça um GET pedido para esse recurso, e garanta que os dados foram salvos corretamente.
• adicionar testes que garantam POST os pedidos falham com dados incorretos ou mal formatados.

para mais algumas ideias sobre scenarios API comuns,confira este post.

PUT

Simlar to POST, PUT requests are used to send data to the API toupdate or create a resource. A diferença é que os pedidos de entradaé idempotente. Isto significa que o mesmo pedido de colocação, várias vezes, produzirá sempre o mesmo resultado. Em contraste, chamar um pedido POST repetidamente faz com que os efeitos colaterais de criar o mesmo recurso várias vezes.

em Geral, quando uma PUT solicitação cria um recurso de servidor willrespond com um 201Created), e se o pedido modifiesexisting recurso, o servidor retornará uma 200OK) ou 204NoContent).

Testing an API with PUT requests

Testing an APIsPUT methods is very similar to testing POSTrequests. Mas agora que sabemos a diferença entre os dois (idempotência), podemos criar testes API para confirmar este comportamento.

verifique estas coisas ao testar coloque os pedidos:

• chamando repetidamente um PUT o pedido devolve sempre o mesmo resultado(idempotente).
• o código de estado apropriado é devolvido ao criar e atualizar um recurso (eg, 201 ou 200204).
• Depois de atualizar um recurso com um PUT pedido, um GET pedido para esse recurso deve retornar os dados corretos.
• PUT os pedidos deverão falhar se forem fornecidos dados inválidos no pedido — nada deverá ser actualizado.

PATCH

Uma PATCH solicitação é um dos menos conhecidos métodos HTTP, mas eu’mincluding ele esta alta na lista, pois é semelhante ao POST andPUT. A diferença com PATCH é que você só aplica modificações parciais ao recurso.

a diferença entre PATCH e PUT, é que o pedido de thataPATCH é não-idempotente (pedido POST da likea).

para expandir a modificação parcial, digamos que a sua API tem um/users/{{userid}} endpoint, e um utilizador tem um nome de utilizador. Com um pedido de aPATCH, você pode apenas precisar enviar o nome de usuário atualizado no organismo de requisição-em oposição ao POST e colocar que exigem a entidade fulluser.

Testing an API with PATCH requests

Since the PATCH method is so simlar to POST and PUT, many of theame testing techniques apply. Ainda é importante validar o comportamento de qualquer ponto final da API que aceite este método.

O que procurar ao testar pedidos de PATCH:

• umPATCH pedido deve devolver um2xx código de Estado.
• PATCH os pedidos deverão falhar se forem fornecidos dados inválidos no pedido — nada deverá ser actualizado.

a semântica dos pedidos de PATCH dependerá em grande parte da API específica que está a testar.

DELETE

The DELETE method is exactly as it sounds: apaga o recurso no URL indicado. Este método é um dos mais comuns em RESTfulAPIs por isso é bom saber como ele funciona.

Testing an API with DELETE requests

DELETE requests should be heavily tested since they generally removedata from a database. Tenha cuidado ao testar métodos de exclusão, Faça com que você esteja usando as credenciais corretas e não testando com dados do realuser.

um caso típico de teste para um pedido de remoção seria semelhante a este:

1. Criar um novo usuário com um POST pedido para /users
2. Com a identificação do usuário retornado a partir de POST fazer uma DELETE pedido para /users/{{userid}}
3. Um subsequentes GET pedido para /users/{{userid}} deve retornar um erro 404 não encontrado código de status.

além disso, o envio de um pedido de remoção para um recurso desconhecido deverá ser enviado para um código de Estado não-200.

HEAD

The HEAD method is almost identical to GET, except without theresponse body. Por outras palavras, se GET /users devolve uma lista de utilizadores, então HEAD /users fará o mesmo pedido, mas não irá recuperar a lista de utilizadores.os pedidos de

HEAD são úteis para verificar o que um pedido de GET irá mudar antes de realmente fazer um pedido de GET — como antes de enviar um ficheiro grande ou um corpo de resposta. Saiba mais sobre os pedidos HEAD no MDN.

vale a pena salientar que nem todos os parâmetros que suportam o GETwill suportam a cabeça – depende completamente da API que está a testar.

Testing an API with HEAD requests

Making API requests with HEAD methods is actually an effective way of simply verifying that a resource is available. É boa prática ter um teste para pedidos de cabeça em todos os lugares que você tem um teste para obter pedidos (desde que a API o suporte).verifique estas coisas ao testar uma API com pedidos de cabeça:

• verifique e verifique os cabeçalhos de um pedido da cabeça
• Faça afirmações contra o código de Estado dos pedidos da cabeça
• teste pedidos com vários parametesr de consulta para garantir os APIresponds

outro caso útil paraHEAD requestsisAPI smoke testing-faça um pedido da cabeça contra cada endpoint da API para garantir que eles está disponível.

opções

Last but not least we have OPTIONS requests. Os pedidos de opções são um dos meus favoritos, embora não tão amplamente utilizados como os outros HTTPmethods. Em poucas palavras, um pedido de opções deve retornar datadescribing que outros métodos e operações o servidor suporta na URL dada.

Os pedidos de opções são mais vagamente definidos e usados do que os outros,tornando-os um bom candidato para testar erros de API fatais. Se anAPI não está esperando um pedido de opções, é bom colocar um lugar de caseína de teste que verifica o comportamento falhando.

testar uma API com pedidos de opções

testar uma OPTIONS o pedido depende do serviço web; se é ou não que suporta isso e o que é suposto retornar definirá como você deve testá-lo.

Como validar um ponto de extremidade usando as OPÇÕES:

• Principalmente, verificar os cabeçalhos de resposta e o código de status do pedido
• Teste de pontos de extremidade que não OPÇÕES de suporte, e garantir que eles failappropriately

Mais recursos

o Que eu tenho discutido acima é apenas um ponto de partida para cavar em toHTTP métodos e testar vários recursos de uma API. Assume também que se trata de um caso ideal – no mundo real, as APIs não estão tão estruturadas como os exemplos acima. Isso faz com que o teste de vários métodos contra uma maneira APIan eficaz para encontrar bugs inesperados.