Eu li muito sobre isso, mas não consigo chegar a uma conclusão sobre o assunto.
Mas eu nunca usei os métodos PUT ou DELETE HTTP Request. Minha tendência é usar GET quando o status do sistema (meu aplicativo ou site) não puder ser afetado (como a lista de produtos) e usar POST quando for afetado (pedido feito). Não é suficiente ou estou faltando alguma coisa?
Respostas:
DELETE é para excluir o recurso de solicitação:
O método DELETE solicita que o servidor de origem exclua o recurso identificado pelo Request-URI. Este método PODE ser anulado por intervenção humana (ou outros meios) no servidor de origem. O cliente não pode garantir que a operação foi realizada, mesmo que o código de status retornado do servidor de origem indique que a ação foi concluída com sucesso ...
PUT é para colocar ou atualizar um recurso no servidor:
O método PUT solicita que a entidade incluída seja armazenada no URI de Solicitação fornecido. Se o Request-URI referir-se a um recurso já existente, a entidade fechada DEVE ser considerada como uma versão modificada daquela que reside no servidor de origem. Se o Request-URI não apontar para um recurso existente e esse URI puder ser definido como um novo recurso pelo agente do usuário solicitante, o servidor de origem pode criar o recurso com esse URI ...
Para ver as especificações completas, visite:
Uma vez que os navegadores atuais infelizmente não suportam quaisquer outros verbos além de POST e GET em formulários HTML , você normalmente não pode utilizar HTTP em toda a sua extensão com eles (você ainda pode sequestrar seu envio via JavaScript). A ausência de suporte para esses métodos em formulários HTML levou a URIs contendo verbos, como por exemplo
POST http://example.com/order/1/delete
ou ainda pior
POST http://example.com/deleteOrder/id/1
encapsulando efetivamente a semântica CRUD sobre HTTP. Mas os verbos nunca foram feitos para fazer parte do URI. Em vez disso, o HTTP já fornece o mecanismo e a semântica para CRUD um Recurso (por exemplo, um pedido) por meio dos métodos HTTP. HTTP é um protocolo e não apenas um serviço de túnel de dados.
Portanto, para excluir um recurso no servidor da web, você chamaria
DELETE http://example.com/order/1
e para atualizá-lo, você ligaria
PUT http://example.com/order/1
e fornecer a representação de recursos atualizada no corpo do PUT para o servidor da web aplicar.
Portanto, se você estiver construindo algum tipo de cliente para uma API REST , provavelmente o fará enviar solicitações PUT e DELETE. Pode ser um cliente construído dentro de um navegador, por exemplo, o envio de solicitações via JavaScript ou pode ser alguma ferramenta em execução em um servidor, etc.
Para mais alguns detalhes visite:
Usar o verbo HTTP Request, como GET, POST, DELETE, PUT etc ... permite que você crie aplicativos da web RESTful. Leia sobre isso aqui: http://en.wikipedia.org/wiki/Representational_state_transfer
A maneira mais fácil de ver os benefícios disso é olhar para este exemplo. Cada estrutura MVC tem um Router/Dispatcherque mapeia URL-s para actionControllers. Portanto, URL como este: /blog/article/1invocará blogController::articleAction($id);
Agora, este roteador está ciente apenas da URL ou/blog/article/1/
Mas se esse roteador estivesse ciente de todo o objeto HTTP Request em vez de apenas URL, ele poderia ter acesso ao verbo HTTP Request (GET, POST, PUT, DELETE ...) e muitas outras coisas úteis sobre o HTTP Request atual.
Isso permitiria que você configurasse o aplicativo para que ele pudesse aceitar o mesmo URL e mapeá-lo para diferentes actionControllers, dependendo do verbo HTTP Request.
Por exemplo:
se você quiser recuperar o artigo 1, pode fazer o seguinte:
GET /blog/article/1 HTTP/1.1
mas se quiser excluir o artigo 1, você fará o seguinte:
DELETE /blog/article/1 HTTP/1.1
Observe que as duas solicitações HTTP têm o mesmo URI, / blog / article / 1, a única diferença é o verbo Solicitação HTTP. E com base nesse verbo, seu roteador pode chamar diferentes actionController. Isso permite que você crie URLs organizados.
Leia estes dois artigos, eles podem ajudá-lo:
Symfony 2 - Fundamentos de HTTP
Estes artigos são sobre o framework Symfony 2, mas podem ajudá-lo a descobrir como funcionam as solicitações e respostas HTTP.
Espero que isto ajude!
Createe 1 para Delete. Se você fizer isso, sua próxima pesquisa será por " Como ter várias ações Post em um único controlador ": P. Não que isso seja terrível, mas você perde a capacidade de implementar um recurso exclusivo por meio do verbo action, em vez de fornecer explicitamente o nome da ação no URI.
Métodos Seguros: Obter Recurso / Nenhuma modificação no recurso
Idempotente: Nenhuma mudança no status do recurso se solicitado muitas vezes
Métodos Inseguros: Criar ou Atualizar Recurso / Modificação no recurso
Não Idempotente: Mudança no status do recurso se solicitado muitas vezes
De acordo com sua exigência:
1) Para operação segura e idempotente (Fetch Resource) use --------- GET METHOD
2) Para operação insegura e não idempotente (Insert Resource) use --------- POST METHOD
3) Para operação insegura e idempotente (Atualizar Recurso), use --------- MÉTODO DE COLOCAÇÃO
3) Para operação insegura e idempotente (Excluir Recurso), use --------- MÉTODO DE EXCLUIR
Embora eu corra o risco de não ser popular, digo que eles não são úteis hoje em dia .
Eu acho que eles foram bem intencionados e úteis no passado quando, por exemplo, DELETE disse ao servidor para excluir o recurso encontrado na URL fornecida e PUT (com seu irmão PATCH) disse ao servidor para fazer a atualização de uma maneira idempotente.
As coisas evoluíram e os URLs tornaram-se virtuais (consulte reescrita de url, por exemplo) fazendo com que os recursos perdessem seu significado inicial de pasta / subfornecedor / arquivo real e, assim, verbos de ação CRUD cobertos por métodos de protocolo HTTP (GET, POST, PUT / PATCH, DELETE) perderam o controle .
Vamos dar um exemplo:
No lado esquerdo não está escrito o método HTTP, essencialmente não importa (POST e GET são suficientes) e no lado direito são usados métodos HTTP apropriados.
O lado direito parece elegante, limpo e profissional. Imagine agora que você precisa manter um código que está usando a API elegante e precisa pesquisar onde a chamada de exclusão é feita. Você pesquisará por "api / entity" e entre os resultados você terá que ver qual está fazendo DELETE. Ou pior ainda, você tem um programador júnior que por engano trocou PUT por DELETE e como URL é a mesma merda aconteceu.
Em minha opinião, colocar o verbo de ação na URL tem vantagens sobre o uso do método HTTP apropriado para essa ação, mesmo que não seja tão elegante. Se você quiser ver onde a chamada de exclusão é feita, você só precisa pesquisar por "api / entidade / excluir" e você encontrará imediatamente.
Construir uma API sem toda a gama de métodos HTTP torna mais fácil de ser consumida e mantida depois