Ano ang mga pangunahing pagkakaiba sa pagitan ng GET at POST HTTP na pamamaraan ng paghiling?

Layunin

• GET ay humihiling ng representasyon ng isang mapagkukunan. Sa pamamagitan ng pagtutukoy ito ay read-only: hindi inaasahan ng kliyente ang anumang pagbabago sa estado ng server. Sinasabi ng RFC 9110 na ang pagpapadala ng katawan sa isang kahilingan sa GET ay may hindi natukoy na semantika, kaya hindi dapat magdala ng katawan ang GET.
• Hinihiling ng POST ang target na mapagkukunan na iproseso ang data na nakapaloob sa nilalaman ng kahilingan ayon sa sariling semantika ng mapagkukunang iyon (lumikha ng tala, magsumite ng form, mag-upload ng file, atbp.).

Saan napupunta ang data

• Ang GET ay nagdadala ng mga parameter sa string ng query ng URL (pagkatapos ng ?, na-format bilang key=value&...). Ang mga ito ay makikita sa address bar at naitala sa kasaysayan ng browser at mga log ng server, at nililimitahan ng praktikal na limitasyon sa haba ng URL.
• Ang POST ay nagdadala ng data sa katawan ng kahilingan; ang uri ay ibinibigay ng Content-Type header. Karaniwang ginagamit ng mga HTML form ang application/x-www-form-urlencoded (ang default) o multipart/form-data (para sa mga file). Walang nakapirming limitasyon sa laki ng antas ng protocol, ngunit kino-configure ng mga server at proxy ang kanilang sariling mga maximum (hal. Nginx client_max_body_size).

Mga katangian sa bawat RFC 9110

• Ligtas: Ang GET ay ligtas (read-only); Ang POST ay hindi.
• Idempotent: Idempotent ang isang kahilingan kung ang paggawa nito ng N beses ay may parehong epekto sa estado ng server gaya ng paggawa nito nang isang beses. Ang GET ay idempotent; Ang POST ay hindi — ang pag-uulit nito ay maaaring lumikha ng mga duplicate, tulad ng dalawang magkaparehong order. Ang Idempotent ay hindi katulad ng ligtas (PUT at DELETE ay idempotent ngunit hindi ligtas), at wala itong sinasabi tungkol sa katawan ng pagtugon na magkapareho.
• Nakaka-cache: Ang mga tugon ng GET ay na-cacheable bilang default; Ang mga tugon ng POST ay na-cache lamang kapag may kasamang tahasang impormasyon sa pagiging bago at isang katugmang Content-Location na header, na bihira sa pagsasanay.

Mga praktikal na implikasyon

• Gamitin ang GET para sa pagkuha at pag-navigate; Ang mga resulta ay maaaring ligtas na maulit, ma-bookmark, at ma-prefetch, at ang pagre-refresh ng GET page ay hindi nakakapinsala.
• Gumamit ng POST para sa mga pagkilos na nagbabago ng estado at para sa pagpapadala ng mga sensitibo o malalaking payload. Ang pag-refresh o pag-navigate pabalik sa isang pahina ng POST ay nagti-trigger ng babala ng browser na "kumpirmahin ang muling pagsusumite ng form."
• Huwag magpadala ng mga password sa pamamagitan ng GET — mapunta sila sa URL, mga log, at kasaysayan. Ito ay kalinisan, hindi pag-encrypt: Ini-encrypt ng HTTPS ang parehong URL at body sa transit, ngunit naka-log pa rin ang URL.

Mga karaniwang follow-up

• Ang mga ligtas na pamamaraan ay GET, HEAD, OPTIONS; ang mga pamamaraan ng idempotent ay GET, HEAD, PUT, DELETE; Ang POST ay hindi rin.
• Ang parehong mga pamamaraan ay sinusuportahan ng mga HTML form (ang katangiang method).
• Ang "Ligtas" sa kahulugan ng RFC ay nangangahulugang walang pagbabago sa estado, hindi proteksyon ng data.
• Ang antas ng aplikasyon na POST idempotency ay kadalasang ipinapatupad gamit ang mga key ng idempotency.