Algumas das outras respostas, incluindo a que foi aceita, recomendam que você use um GET (embora não muito entusiasticamente).
Eu não concordo.
Primeiro de tudo, todos os outros dizendo que isso não é ideal e não é realmente RESTful estão corretos. Em um cenário RESTful apropriado, você está manipulando recursos no servidor e adicionando, atualizando, excluindo, recuperando, etc. esses recursos. Um PUT deve enviar uma carga útil que represente qual deve ser o recurso quando a solicitação for concluída, e o POST deve enviar uma carga útil que represente um recurso a ser adicionado ao servidor. E um GET deve retornar um recurso no servidor.
Você tem um RPC (chamada de procedimento remoto), que não é RESTful - você quer fazer algo no servidor. Portanto, se você estiver tentando criar uma API puramente RESTful, reconsidere o que está fazendo.
Dito isto, às vezes você precisa dobrar as regras um pouco. Especialmente se você estiver desenvolvendo uma API interna que não será exposta ao público, você pode decidir que a compensação vale a pena.
Se você fizer isso, eu recomendaria um PUT ou POST, dependendo se o RPC é ou não idempotente ou não .
Em geral, dizemos que o HTTP PUT mapeia para o SQL UPDATE e que o HTTP POST mapeia para o SQL INSERT, mas isso não é estritamente verdadeiro. Uma forma mais pura de afirmar que HTTP PUT deve ser idempotente e HTTP POST não precisa ser. Isso significa que você pode chamar a mesma solicitação PUT quantas vezes quiser sem efeitos colaterais. Uma vez que você ligou uma vez, é inofensivo ligar novamente. Mas você não deve chamar repetidamente as solicitações POST, a menos que você queira - cada POST altera os dados no servidor novamente.
No seu caso, se você precisar dessa função de recarga, eu recomendaria um PUT porque parece que é idempotente. Mas eu ainda gostaria que você considerasse o que os outros disseram sobre não precisar disso.