HTTP POST com parâmetros de consulta de URL - boa idéia ou não? [fechadas]

Question

Eu estou projetando uma API para passar por cima de HTTP e eu estou querendo saber se usando o comando HTTP POST, mas com parâmetros de consulta de URL apenas e nenhum corpo da solicitação, é um bom caminho a percorrer.

Considerações:

• "bom design Web" requer ações não-idempotentes para ser enviado via POST. Esta é uma ação não-idempotent.
• É mais fácil desenvolver e depurar este aplicativo quando os parâmetros do pedido estão presentes na URL.
• A API não é destinado para uso generalizado.
• Parece que fazer uma solicitação POST com nenhum corpo vai demorar um pouco mais de trabalho, por exemplo, um cabeçalho Content-Length: 0 deve ser adicionado explicitamente.
• Também me parece que um POST com nenhum corpo é um contador pouco para e HTTP estruturas das expectativas de mais desenvolvedores.

Existem mais armadilhas ou vantagens para o envio parâmetros em um pedido POST através da consulta de URL em vez do corpo da solicitação?

Edit: A razão pela qual este está sob consideração é que as operações não são idempotent e tem outras que a recuperação efeitos colaterais. Consulte o HTTP especificação :

Em particular, a convenção foi estabelecido que o GET e HEAD métodos não deve ter o importância de tomar uma ação outra de recuperação. Estes métodos deveriam ser considerado "seguro". Isso permite que o usuário agentes para representar outros métodos, tais como o POST, PUT e excluir, numa modo especial, para que o usuário é feita ciente do fato de que um possivelmente ação insegura está sendo solicitado.

...

Os métodos também podem ter a propriedade de "Idempotência" em que (além de questões de validade de erro ou) o efeitos colaterais de N> 0 idêntico pedidos é o mesmo que para uma única solicitação. Os métodos GET, HEAD, PUT e compartilhar Apagar esta propriedade. Além disso, os métodos opções e rastreamento deve Não tem efeitos colaterais, e por isso são inerentemente idempotent.

Answer 1

Se a sua ação não é idempotente, então você deve uso POST. Se você não fizer isso, você está apenas pedindo para ter problemas para baixo da linha. métodos GET, PUT e DELETE são necessário ser idempotent. Imagine o que aconteceria em sua aplicação se o cliente foi pré-busca cada possível pedido GET para o seu serviço -. Se isso iria causar efeitos colaterais visíveis para o cliente, então errado de algo

Eu concordo que o envio de uma POST com uma string de consulta, mas sem um corpo parece estranho, mas eu acho que pode ser apropriada em algumas situações.

Pense na parte de consulta de um URL como um comando para o recurso para limitar o escopo da solicitação atual. Normalmente, seqüências de consulta são usados ??para classificar ou filtrar um pedido GET (como ?page=1&sort=title), mas eu acho que faz sentido em um POST também limitar o escopo (talvez como ?action=delete&id=5).

Answer 2

Todo mundo tem razão:. Vara com POST para solicitações não-idempotentes

Que tal usar tanto uma string de consulta URI eo conteúdo do pedido? Bem, é HTTP válido (ver nota 1), então por que não!

Também é perfeitamente lógico: URLs, incluindo a sua parte de cadeia de consulta, são para localização recursos. Considerando HTTP verbos método (POST - e seu conteúdo pedido opcional) são para ações que especificam ou o que fazer com recursos. Aqueles devem ser preocupações ortogonais. (Mas, eles não são preocupações lindamente ortogonais para o caso especial de ContentType = application / x-www-form-urlencoded, ver nota 2 abaixo).

Nota 1: HTTP especificação (1.1) não afirma que os parâmetros de consulta e conteúdo são mutuamente exclusivas para um servidor HTTP que aceita solicitações POST ou PUT. Assim, qualquer servidor é livre para aceitar ambos. Ou seja, se você escrever o servidor não há nada para impedi-lo escolher a aceitar ambos (exceto, talvez, um quadro inflexível). Geralmente, o servidor pode interpretar consulta cordas de acordo com quaisquer regras que quer. Ele pode até mesmo interpretá-los com lógica condicional que se refere a outros cabeçalhos como Content-Type também, o que leva a Nota 2:

Nota 2: se um browser é a principal forma as pessoas estão acessando o aplicativo web, e application / x-www-form-urlencoded é o Content-Type eles são postagem, então você deve seguir as regras para que Content-Type. E as regras para application / x-www-form-urlencoded são muito mais específico (e, francamente, incomum): neste caso, você deve interpretar o URI como um conjunto de parâmetros, e não um local de recursos. [Este é o mesmo ponto de utilidade Powerlord levantada; que pode ser difícil de usar formulários web para postar conteúdo para o seu servidor. Apenas explicou um pouco diferente.]

Nota 3: quais são seqüências de consulta originalmente para? RFC 3986 define HTTP consulta cordas como parte URI que funciona como uma forma não-hierárquica de localizar um recurso.

Em leitores caso esta pergunta desejo de perguntar o que é boa arquitetura RESTful: o padrão de arquitetura RESTful não requer esquemas URI para trabalhar de forma específica. arquitetura RESTful se preocupa com outras propriedades do sistema, como cacheability de recursos, o design dos recursos eles mesmos (os seus comportamentos, capacidades e representações), e se idempotência está satisfeito. Ou em outras palavras, alcançando um design que é altamente compatível com o protocolo HTTP e seu conjunto de HTTP verbos método. :-) (Em outras palavras, a arquitetura RESTful não é muito presciptive com a forma como os recursos são localizado .)

Nota final: por vezes, os parâmetros de consulta se acostumar para ainda outras coisas, que não são nem localizar recursos nem codificação de conteúdo. Já viu um parâmetro de consulta como 'PUT = true' ou 'POST = true'? Estes são soluções alternativas para navegadores que não permitem que você use métodos PUT e POST. Embora tais parâmetros são vistos como parte da seqüência de consulta URL (no fio), argumento que não fazem parte de consulta da URL em espírito .

Answer 3

Você quer que razões? Aqui está um:

Um formulário web não pode ser usado para enviar um pedido para uma página que usa uma mistura de GET e POST. Se você definir o método do formulário para GET, todos os parâmetros são na cadeia de consulta. Se você definir o método do formulário para o POST, todos os parâmetros são no corpo da solicitação.

Fonte: 4,01 padrão HTML, seção 17.13 Formulário de Apresentação

Answer 4

Do ponto de vista programático, para o cliente é embalar os parâmetros e anexando-os para a url e realização de um POST vs. um GET. No lado do servidor, é avaliar os parâmetros de entrada do querystring em vez dos bytes postados. Basicamente, é uma lavagem.

Onde poderia haver vantagens / desvantagens pode estar em how específico plataformas cliente trabalhar com POST e GET rotinas em sua pilha de rede, bem como a forma como o servidor web lida com esses pedidos. Dependendo da sua aplicação, uma abordagem pode ser mais eficiente do que o outro. Sabendo que iria orientar sua decisão aqui.

No entanto, a partir da perspectiva de um programador, eu prefiro permitindo que qualquer um POST com todos os parâmetros no corpo, ou um GET com todos os parâmetros na URL, e ignorando explicitamente parâmetros de URL com qualquer pedido POST. Ele evita confusão.

Answer 5

Eu acho que ainda poderia ser bastante RESTful ter consulta argumentos que identificam o recurso no URL, mantendo a carga útil conteúdo confinado ao corpo POST. Isto parece separar as considerações de "O que estou enviando?" versus "Quem sou eu enviá-lo para?".

Answer 6

RESTO tem alguns princípios orientadores que podemos usar para padronizar a maneira como usamos HTTP verbos. Isso é útil quando a construção de API RESTful é como você está fazendo.

Em poucas palavras: GET deve ser Read Only ou seja, não têm efeito sobre o estado do servidor. POST é usado para criar um recurso no servidor. PUT é usado para atualizar ou criar um recurso. DELETE é usado para excluir um recurso.

Em outras palavras, se a sua acção API altera o estado do servidor, REST nos aconselha a usar POST / PUT / DELETE, mas não ficar.

Os agentes de usuário geralmente entender que fazer várias postagens é ruim e vai alertar contra ela, porque a intenção do POST é o estado do servidor alter (eg. Pagamento de bens no check-out), e você provavelmente não quer fazer isso duas vezes !

Comparar a um GET que você pode fazer um frequentemente como você gosta (idempotent).

Answer 7

Concordo - é provavelmente mais seguro usar uma solicitação GET se você está só de passagem de dados no URL e não no corpo. Consulte esta questão semelhante para algumas vistas adicionais no todo conceito GET POST +.