POST

Penggunaan

Permintaan POST mengirimkan sebuah entitas ke sumber daya yang ditentukan. Server menentukan cara menangani representasi yang disertakan berdasarkan semantik sumber daya itu sendiri. Tidak seperti PUT, yang menyasar URI sumber daya tertentu, POST mendelegasikan pemrosesan kepada sumber daya yang diidentifikasi oleh URI target.

Header Content-Type menunjukkan format badan permintaan. Tiga encoding umum dipakai dalam formulir HTML dan API.

application/x-www-form-urlencoded

Encoding bawaan untuk formulir HTML. Data disusun sebagai pasangan kunci-nilai yang dipisahkan oleh tanda ampersand (&), dengan kunci dan nilai dihubungkan oleh tanda sama dengan (=). Karakter non-alfanumerik menggunakan Percent-Encoding.

name=Alice&role=admin

multipart/form-data

Setiap ruas menempati bagian terpisah yang dibatasi oleh string boundary yang dideklarasikan dalam header Content-Type. Encoding ini mendukung data biner seperti unggahan berkas. Header Content-Disposition di dalam setiap bagian memberi nama ruas tersebut.

text/plain

Tidak ada struktur yang ditentukan. Server memproses badan mentah menurut logikanya sendiri.

Permintaan POST yang diulang tidak idempoten. Mengirimkan formulir yang sama dua kali akan membuat dua sumber daya atau memicu pemrosesan dua kali, berbeda dengan PUT yang permintaan berulangnya menghasilkan keadaan server yang sama.

Respons POST hanya dapat di-cache ketika respons menyertakan informasi kesegaran yang eksplisit dan header Content-Location yang cocok.

Pengiriman formulir

Klien mengirimkan data formulir menggunakan format URL-encoded. Server membuat sebuah pekerjaan dan membalas dengan 201 Created.

Permintaan

POST /jobs HTTP/1.1
Host: api.example.re
Content-Type: application/x-www-form-urlencoded
Content-Length: 17

name=backup&pri=2

Respons

HTTP/1.1 201 Created
Location: /jobs/47
Content-Type: application/json
Content-Length: 38

{"id":47,"name":"backup","priority":2}

Unggah berkas multipart

Klien mengunggah sebuah berkas menggunakan encoding multipart. String boundary ----Boundary memisahkan setiap bagian. Server menerima unggahan tersebut dan mengembalikan 202 Accepted.

Permintaan

POST /uploads HTTP/1.1
Host: api.example.re
Content-Type: multipart/form-data; boundary=----Boundary
Content-Length: 196

------Boundary
Content-Disposition: form-data; name="title"

Q4 Report
------Boundary
Content-Disposition: form-data; name="file"; filename="report.pdf"
Content-Type: application/pdf

<binary data>
------Boundary--

Respons

HTTP/1.1 202 Accepted
Location: /uploads/91
Content-Length: 0

JSON API

Klien mengirimkan payload JSON untuk membuat pengguna baru. Server mengembalikan sumber daya yang dibuat beserta ruas id.

Permintaan

POST /users HTTP/1.1
Host: api.example.re
Content-Type: application/json
Content-Length: 41

{"email":"alice@example.re","role":"ops"}

Respons

HTTP/1.1 201 Created
Content-Type: application/json
Content-Length: 50

{"id":112,"email":"alice@example.re","role":"ops"}

CORS

POST adalah metode yang masuk daftar aman CORS, tetapi hanya ketika Content-Type berupa application/x-www-form-urlencoded, multipart/form-data, atau text/plain. POST dengan application/json atau tipe konten lainnya akan memicu permintaan preflight OPTIONS.

POST vs GET

POST membawa data di badan permintaan, bukan di URL. Hal ini menjauhkan parameter dari riwayat browser, log server, dan header Referer, sehingga POST lebih cocok untuk data sensitif.

Respons POST tidak di-cache secara bawaan dan tidak dapat ditandai sebagai bookmark. POST tidak aman maupun idempoten, sehingga pengiriman berulang akan membuat sumber daya duplikat atau memicu pemrosesan berkali-kali.

POST secara praktis tidak memiliki batas ukuran badan, sedangkan GET dibatasi oleh batas panjang URL sekitar 2048 karakter.

Cookie dengan SameSite=Lax memblokir permintaan POST lintas situs tetapi mengizinkan GET lintas situs. Hal ini memberi POST tingkat perlindungan CSRF bawaan yang tidak dimiliki GET.

Keamanan

Data POST tidak muncul di URL, riwayat browser, atau header Referer. Dibandingkan GET, hal ini mengurangi risiko terbukanya data secara tidak sengaja.

POST tetap rentan terhadap serangan CSRF tanpa token yang memadai. Formulir pada halaman berbahaya mengirimkan permintaan POST ke origin lain secara otomatis. Cookie SameSite=Lax memberikan perlindungan sebagian dengan memblokir pengiriman cookie pada POST lintas situs, tetapi token CSRF khusus tetap diperlukan.

POST melalui HTTP biasa mengirimkan data dalam bentuk teks terbuka. HTTPS diperlukan untuk melindungi badan permintaan selama pengiriman.

POST vs PATCH

POST membuat sumber daya baru pada URI yang dipilih server. PATCH memodifikasi sumber daya yang sudah ada pada URI yang diketahui.

POST mendelegasikan semantik pemrosesan sepenuhnya kepada server. PATCH memiliki format patch yang terdefinisi seperti JSON Patch dan JSON Merge Patch yang menjelaskan modifikasi spesifik yang akan diterapkan.

Ketika klien perlu memperbarui ruas tertentu pada sumber daya yang sudah ada, PATCH adalah metode yang tepat. POST digunakan untuk membuat sumber daya baru atau memicu pemrosesan di sisi server.