Mixing GET con POST - è una cattiva pratica?

Question

È una cattiva pratica mescolare GET e POST? (nota questo è in PHP)

ad es.

<form action="delete.php?l=en&r=homepage" method="post"> 
<!-- post fields here --> 
</form> 

Answer 1

In realtà, questo invierà una richiesta richiesta POST al server, quindi tecnicamente non si è mescolare le due cose insieme: si utilizza POST con parametri URL. Non c'è nulla di fondamentalmente sbagliato in questo, a patto che non si usi l'URL per i parametri che dovrebbero essere nella forma come campo nascosto.

Esistono semplici regole: si utilizza GET (possibilmente con parametri URL) per cose costanti che non cambiano server e POST per cose che modificano il server. Se i parametri dell'URL contenessero l'ID di qualcosa che volevi eliminare, sarebbe una cattiva pratica.

EDIT, anni dopo

mi è stato chiesto per la fonte, per cui qui sono la parte rilevante del molto specifiche di HTTP

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

la convenzione è stato stabilito che il GET I metodi e HEAD NON DEVONO avere l'importanza di intraprendere un'azione diversa dal recupero. Questi metodi devono essere considerati "sicuri". Ciò consente agli agenti utente di rappresentare altri metodi, come POST, PUT e DELETE, in un modo speciale, in modo che l'utente venga reso consapevole del fatto che è possibile richiedere un'azione potenzialmente non sicura.

Ci si va, GET non dovrebbe cambiare nulla, il POST è per cose che cambiano il server (operazione non sicura). Dovrei essere in grado di chiamare GET qualsiasi numero di volte. È più che idempotente: dovrebbe essere (per quanto possibile) privo di effetti collaterali! Con GET la richiesta potrebbe non raggiungere nemmeno il server se è implicata la cache.

Quindi sì: hai un modulo, vuoi sapere se usi GET o POST? Quindi cambia server => POST, non cambiare server => GET. E poiché si può accedere a un URL con qualsiasi verbo (get o post), non inserire i dati che modificano il server nell'URL, perché qualcuno potrebbe copiare quell'URL, fare un GET e cambiare il server senza che tu lo sappia. Immagina cosa succederebbe se qualcuno copiasse quell'URL su facebook e 10 000 persone iniziassero a cancellare cose casuali? Non bene. I framework recenti (node, ruby) sono meglio isolati rispetto a quelli, ma non in PHP di base, quindi è una buona regola per quel linguaggio.

Answer 2

È ancora un POST, si include solo una stringa di query nell'URL. Non vedo un problema con questo. Questo è probabilmente più pulito che include quelle variabili nei dati del post usando i campi di input nascosti. Inoltre, sul server, probabilmente non si desidera il valore di l (lingua?) Con i dati del post. Se è sempre presente nella stringa di query, puoi determinare lo stesso codice altrove per determinare la lingua, anziché avere un caso speciale per le richieste POST.

Answer 3

No, questo va bene. Faccio esattamente questo sul sito Web della mia azienda, ad esempio nella pagina di amministrazione degli utenti.L'URL normale è:

/admin/user?name=jkugelman 

Poi per eliminare un utente ho posto a questa stessa pagina, tranne che vi posto una variabile invece di fare un GET, dal momento che la cancellazione è un'azione stateful e dovrebbe essere fatto con un post. Sembra qualcosa di simile:

<!-- Post back to self --> 
<form action="/admin/user?name=jkugelman"> 
    <input type="submit" name="delete" value="Delete" 
      onchange="return confirm('Are you sure?')" /> 
</form>