Mike amundsen fez essa pergunta em um post que examinava alternativas para construir um serviço RESTful em ambientes onde você só têm as opções de escolher GET e POST.
As vezes quando estou em uma discussão sobre arquitetura REST algum participante sempre tem a impressão de que,a menos que você utilize os métodos HTTP PUT e DELETE, sua aplicação não é RESTful. Isso não é correto.
Com o intuito de encontrar a resposta para essa questão ele responde a uma série de perguntas que buscam provar que, se você estiver utilizando os métodos HTTP para as operações apropriadas, seu serviço pode ser considerado RESTful.
Isso é seguro?
Ele enfatiza que os métodos HTTP podem ser determinantes na segurança da aplicação. Se a intenção da operação, expressada via métodos HTTP, e a implementação dela corresponderem, a operação é considerada segura.
é importante que as implementações não utilizem métodos seguros (e.g. GET and HEAD) para executar operação inseguras (e.g. escrever dados). [...] dado que o HTTP define o GET como "seguro", os caches e outros proxies irão assumir (baseado na especificação) que não existe problemas em realizar "pre-fetch" nas URIs e/ou cachear ou repitir as respostas quando necessário.
Apenas o POST não é o suficiente? [Nós precisamos de PUT e DELETE para realizar operações inseguras?]
Embora boa parte dos exemplos e da literatura disponível sobre o assunto sugerem que não é suficiente, ele enfatiza que as interfaces dos serviços RESTful nem sempre são apenas CRUD.
[...] outro pensamento comum é que se utilizarmos apenas o POST para todas as nossas operações o serviço não é RESTful. Em outras palavras, você não pode dizer que sua implementação suporta REST a menos que ela utilize PUT e/ou DELETE. Essa suposição incorreta é um efeito colateral de ver REST apenas com operações CRUD; que REST == CRUD sobre o HTTP. Novamente é possível se ter um CRUD sobre o HTTP, mas isso não é REST; isso é um CRUD sobre HTTP.
Ele cita Roy Fielding, que afirma que "É correto utilizar POST".
Nós não precisamos utilizar o PUT para todas as mudanças de estado no HTTP. O REST nunca disse que nós teriamos que utilizar.
Mas eu realmente posso fazer tudo apenas com GET e POST?
"claro que você pode"; Ele diz "isso tem sido feito por muitos anos. Nenhuma mágica é necessária. sem headers speciais; sem argumentos action na URI; sem parametros de método no corpo da mensagem". Ele mostra um exemplo de operações em fila em um servidor.
por exemplo, expor recursos públicos onde a escrita é feita via requisições que são adicionadas em uma lista para um pós-processamento:
POST /users/pending-updates/
OU
POST /users/pending-deletes/
Esse modelo é muito similar a idéia de Tim Bray no design da API da VM Sun, no qual ele se refere a isso como Slow REST. A idéia foi baseada na proposta de Craig MacLanahan's para Manipulação Assíncrona de Operações de Request.
Toda e qualquer operação PUT/POST/DELETE, nos retornava "202 In progress" e um novo "status" do recurso, que continha um indicador de progresso que ia de 0 até 100, um target_uri para onde a aplicação deveria ir, e um op para identificar a operação. Quando o progresso atingisse 100, eram enviados o campos status e mensagem.
Mike conclui seu post dizendo que, para situações onde o uso dos métodos HTTP é limitado pela rede ou pelos clientes fazendo com que só seja possível utilizar GET ou POST, o serviço precisa fazer ajustes que "guiem" o cliente para a representação, para o método HTTP e uri's corretamente.
described in dado que o HTTP abstrai as interações em recursos com representações direcionadas via URIs, fazer ajustes em tempo de execução não só é possível como está no design do protocolo. Ao combinar esses níveis de abstração com as restrições de hypermedia descritas na dissertação de Roy Fielding você pode conseguir uma aplicação muito flexível que não só é compatível com o HTTP, mas também apoia os princípios fundamentais da arquitetura REST em vários ambientes, mesmo aqueles restritos ao uso somente do GET e POST.
Para mais informações não deixe de ler o post original.