Por que precisamos de algo mais do que HTTP GET, PUT, POST?

Question

Qual é o benefício prático de usar HTTP GET, PUT, DELETE, POST, HEAD? Por que não se concentrar em seus benefícios comportamentais (segurança e idempotency), esquecendo seus nomes, e uso GET, PUT ou POST dependendo de qual o comportamento que queremos?

Por que não devemos usar apenas GET, PUT e POST (e queda de cabeça, DELETE)?

Answer 1

O [DESCANSO] [1] abordagem usa POST, GET, PUT e DELETE para implementar as regras CRUD para um recurso web. É uma maneira simples e arrumada para expor objetos para solicitações na web. É serviços web sem as despesas gerais.

Só para esclarecer as diferenças semânticas. Cada operação é bastante diferente. O ponto é ter métodos HTTP agradáveis ??que têm significados claros e distintos.

POST cria novos objetos. O URI não tem chave; ele aceita um corpo de mensagem que define o objeto. SQL Insert. [ Editar Enquanto não há nenhuma razão técnica para POST ter nenhuma tecla, o pessoal do REST sugerem fortemente que para POST ter significado distinto como CREATE, ele não deve ter uma chave.]

GET Recupera objetos existentes. O URI pode tem uma chave, depende se você está fazendo Singleton GET ou lista GET. SQL Select

PUT atualiza um objeto existente. O URI tem uma chave; Ele aceita um corpo de mensagem que atualiza um objeto. SQL Update.

Exclui excluir um objeto existente. O URI tem uma chave. SQL Excluir.

Você pode atualizar um registro com POST em vez de PUT? Não sem introduzir alguma ambiguidade. Verbos deve ter efeitos ambíguos. Além disso, POST URI não têm chave, onde PUT deve ter uma chave.

Quando eu POST, ESPERO 201 CRIADO. Se eu não conseguir isso, errado de alguma coisa. Da mesma forma, quando eu coloco, eu espero um 200 OK. Se eu não conseguir isso, errado de alguma coisa.

Eu suponho que você poderia insistir em alguma ambiguidade onde POST faz POST ou PUT. O URI tem de ser diferente; também a mensagem associada poderia ser diferente. Geralmente, o pessoal do REST aproveitar a sugestão do SQL onde INSERT e atualização são diferentes verbos.

Você poderia fazer o caso que atualização deve inserir se o registro não existe ou atualização se o registro existe. No entanto, é mais simples se os meios Update Atualização e falta de errado meio de atualização de algo. A queda-back segredo para inserir torna a operação ambígua.

Se você não está construindo uma interface RESTful, então é típico apenas GET uso e POST para recuperar e criar / atualização. É comum ter diferenças URI ou diferenças de conteúdo mensagem para distinguir entre POST e PUT quando uma pessoa é clicar em enviar em um formulário. Ele, no entanto, não é muito limpo, porque o seu código tem de determinar se você está no POST = criar caso ou POST = caso de atualização.

Answer 2

POST não tem garantias de segurança ou idempotency . Essa é uma razão para PUT e Excluir -ambos PUT e DELETE são idempotent (ou seja, 1 + N pedidos idênticos têm o mesmo resultado final como apenas 1 pedido).

PUT é usado para definição o estado de um recurso em um determinado URI. Quando você envia um POST solicitação para um recurso em um determinado URI, esse recurso não deve ser substituir pelo conteúdo. No máximo, deve ser Em anexo para. É por isso que POST não é idempotente-no caso de anexação POSTS, cada pedido vai acrescentar ao recurso (por exemplo, postar um new mensagem para um fórum de discussão de cada vez).

Excluir é usado para garantir que um recurso em um determinado URI é removida do servidor. POST não deve ser normalmente utilizados para apagar exceto para o caso de submeter uma solicitação para excluir. Mais uma vez, o URI do recurso que você ia postar nesse caso, não deve ser o URI para o recurso que deseja excluir. Qualquer recurso para o qual você postar em é um recurso que aceita os dados postados para anexar a si mesmo, adicionar a uma coleção, ou processo de alguma outra forma.

CABEÇA é usado se tudo o que interessa é os cabeçalhos de uma requisição GET e você não quer desperdiçar largura de banda no conteúdo real. Isto é bom ter.

Answer 3

Por que precisamos mais de POST? Ele permite que os dados fluam em ambos os sentidos, então por que iria se necessário? A resposta é basicamente o mesmo que para a sua pergunta. Ao padronizar as expectativas básicas dos vários métodos de outros processos podem conhecer melhor o que fazer.

Por exemplo, intervindo caching proxies pode ter uma melhor chance de fazer a coisa correta.

Pense CABEÇA por exemplo. Se o servidor proxy sabe o que CABEÇA significa, então ele pode processar o resultado de uma solicitação GET anterior para dar a resposta adequada a um pedido HEAD. E pode saber que POST, PUT e DELETE não deve ser armazenada em cache.

Answer 4

Ninguém postou o tipo de resposta que eu estava procurando por isso vou tentar resumir os pontos mim mesmo.

seção do capítulo 8 "RESTful Web Services" "A sobrecarga POST" lê: "Se você quer fazer sem PUT e DELETE completamente, é inteiramente RESTful para expor a segurança das operações sobre os recursos através de GET, e quaisquer outras operações através de POST sobrecarregado Fazendo. isso viola minha Arquitetura Orientada a Resource, mas está em conformidade com as regras menos restritivas de descanso. "

Em suma, substituindo PUT / DELETE em favor do POST faz a API mais difícil de ler e colocar / chamadas de DELETE não idempotent são.

Answer 5

Em uma palavra:

idempotency

Em mais algumas palavras:

GET = seguro + idempotent

PUT = idempotent

Excluir = idempotent

POST = nem seguro ou idempotent

'idempotente' apenas significa que você pode fazê-lo uma e outra vez e ele vai sempre fazer exatamente a mesma coisa.

Você pode reeditar um PUT (actualização) ou solicitação DELETE tantas vezes quanto você quer e ele vai ter o mesmo efeito de cada vez, no entanto, o efeito desejado vai modificar um recurso para que ele não é considerado 'seguro'.

pedido

A POST deve criar um novo recurso com cada pedido, ou seja, o efeito será diferente a cada vez. Portanto POST não é considerado seguro ou idempotent.

Métodos como GET e cabeça são apenas operações de leitura e, portanto, são considerados 'seguros' nele assim como idempotent.

Este é realmente um conceito muito importante porque fornece uma forma padrão / consistentes para interpretar transações HTTP; isso é particularmente útil em um contexto de segurança.

Answer 6

Nem todos os hosters não suportam PUT, DELETE.

Eu fiz esta pergunta, em um mundo ideal, teríamos todos os verbos, mas ....:

RESTful serviços web e HTTP verbos

Answer 7

CABEÇA é realmente útil para determinar o relógio de um determinado servidor está definido para (precisão de 1 segundo ou o tempo de ida e volta de rede, o que for maior). Também é ótimo para obter cotações Futurama do Slashdot:

~$ curl -I slashdot.org
HTTP/1.1 200 OK
Date: Wed, 29 Oct 2008 05:35:13 GMT
Server: Apache/1.3.41 (Unix) mod_perl/1.31-rc4
SLASH_LOG_DATA: shtml
X-Powered-By: Slash 2.005001227
X-Fry: That's a chick show. I prefer programs of the genre: World's Blankiest Blank.
Cache-Control: private
Pragma: private
Connection: close
Content-Type: text/html; charset=iso-8859-1

Para cURL , -I é a opção para a realização de um pedido HEAD. Para obter a data e hora atual de um determinado servidor, basta fazer

curl -I $server | grep ^Date

Answer 8

Para ambigüidade limite que irá permitir uma melhor reutilização / mais fácil de nossos APIs simples descanso.

Answer 9

Você pode usar somente GET e POST, mas então você está perdendo um pouco da precisão e clareza que PUT e DELETE trazer. POST é uma operação curinga que poderia significar qualquer coisa. comportamento PUT e de exclusão é muito bem definida. Se você pensar em uma API de gerenciamento de recursos, em seguida, GET, PUT e DELETE provavelmente cobrir 80% -90% da funcionalidade necessária. Se você se limitar a GET e POST, em seguida, 40% -60% do seu api é acessado usando o POST mal especificado.

Answer 10

aplicações Web usando GET e POST permitem aos usuários criar, visualizar, modificar e apagar seus dados, mas fazê-lo em uma camada acima os comandos HTTP originalmente criados para esses fins. Uma das idéias por trás REST é um retorno à intenção original do desenho da Web, em que há operações HTTP específicas para cada verbo CRUD.

Além disso, o comando cabeça pode ser usado para melhorar a experiência do usuário para (potencialmente grande) downloads de arquivos. Você chama HEAD para descobrir o quão grande é a resposta vai ser e depois GET chamada para realmente recuperar o conteúdo.

Answer 11

Veja o seguinte ligação para um exemplo ilustrativo. Ele também sugere uma maneira de usar as opções http método, que ainda não foi discutido aqui.

Answer 12

Existem http extensões como WebDAV que exigem funcionalmente adicional.

http://en.wikipedia.org/wiki/WebDAV

Answer 13

A guerra servidor web desde os dias anteriores provavelmente causou.

Na HTTP 1.0 escrito em 1996, só foram GET, HEAD e POST . Mas, como você pode ver na Apêndice D , os vendedores começaram a adicionar a sua coisas próprias. Assim, para manter HTTP compatível, eles foram forçados a fazer HTTP 1.1 em 1999 .

No entanto, HTTP / 1.0 não tem suficientemente em consideração os efeitos de proxies hierárquicos, caching, a necessidade de conexões persistentes, ou hosts virtuais. Além disso, a proliferação aplicações de forma incompleta implementados que se autodenominam "HTTP / 1.0" exigiu uma mudança versão do protocolo, a fim de dois aplicativos que se comunicam para determinar uns aos outros de verdadeiras capacidades.

Esta especificação define o protocolo referido como "HTTP / 1.1". Este protocolo inclui exigências mais rigorosas do que de HTTP / 1.0 em ordem para assegurar a implementação confiável de suas características.

Answer 14

GET, PUT, DELETE e POST são remanescentes de uma era em que sophomores pensei que uma página web poderia ser reduzida a princípios a poucos hoighty-toity.

Hoje em dia, a maioria das páginas da web são entidades compostas, que contêm alguns ou todos estes operações primitivas. Por exemplo, uma página poderia ter formas para visualizar ou atualizar as informações dos clientes, o que talvez se estende por uma série de tabelas.

Eu costumo usar $ _REQUEST [] em php, não realmente cuidar como a informação chegou. Eu iria escolher para usar GET ou PUT métodos baseados na eficiência, não os subjacentes (múltiplos) paradigmas.