Lo developer backend. Dapet request: bikin search API dengan 15 parameter filter, sorting, pagination, aggregation - plus user bisa milih field mana aja yang mau dikembaliin.

Nulis GET endpoint? Query string-nya jadi super panjang, url-encoded complex values, error-prone, dan browser/load balancer punya batas panjang URL (biasanya 8KB).

Nulis POST? Teknisnya sih work - tapi POST gak idempotent. Search yang sama diulang 2x seharusnya balikin hasil yang sama. POST ngelanggar semantik HTTP.

Lo stuck di antara dua pilihan yang sama-sama gak ideal. Nah, HTTP sebenernya punya lebih banyak method dari yang lo pake sehari-hari. Dan beberapa di antaranya - termasuk yang cukup baru - bisa jadi solusi buat kasus kayak gini.

QUERY - GET Dengan Body, Resmi Standar

Ini yang paling menarik. RFC 9651 resmi dipublikasi September 2024 sebagai Proposed Standard. Ada dua penulis: Roy Fielding (ya, bapak REST sendiri) dan Julian Reschke.

Cara Kerja

QUERY itu safe dan idempotent - sama kayak GET. Artinya:

  • Gak ngubah state server
  • Request yang sama dikirim berkali-kali -> hasilnya sama
  • Bisa di-cache proxy/CDN

Yang bikin QUERY beda dari GET: boleh punya request body. Jadi complex query bisa lo masukin sebagai JSON di body, bukan di query string yang rentan truncated.

QUERY /api/products HTTP/1.1
Content-Type: application/json
Accept: application/json

{
  "filters": {
    "category": "electronics",
    "price_min": 100000,
    "price_max": 5000000,
    "in_stock": true
  },
  "sort": { "field": "price", "order": "asc" },
  "fields": ["name", "price", "stock"],
  "page": 1,
  "per_page": 20
}

Penggunaan Sehari-hari

Di bayangan gue, ini ideal buat:

  • Data grid/table - frontend yang render tabel interaktif (filter + sort + pagination + column selection). Body JSON lebih abundant dan gampang di-parsing daripada query string.
  • GraphQL-like queries - client minta field spesifik dari response. Body QUERY bisa jadi semacam DSL ringan tanpa perlu infra GraphQL.
  • Bulk status check - cek status ratusan ID sekaligus. Lo kirim array ID di body, dapet array status balik.
  • Machine-to-machine API - antar service internal yang hubungannya read-only tapi butuh criteria kompleks.

Cache-nya juga jalan: proxy bisa cache QUERY response berdasarkan Content-Location header yang server tentuin. Jadi kalo dua client kirim QUERY yang identik, mereka bisa dapet response dari cache.

Fun Fact

RFC 9651 literally bilang ini method baru pertama yang dibikin Roy Fielding sejak HTTP/1.1. Setelah 25 tahun REST, baru sekarang dia nambah method baru. Alasan dia nulis RFC ini? Karena semenjak 2015-an makin banyak API yang pake POST buat search - dan itu secara semantik salah. Fielding nulis ini buat kasih opsi yang proper tanpa nyuruh orang pake GET yang query string-nya gila-gilaan.

PURGE - Method Favorit CDN

PURGE bukan method resmi HTTP. Gak ada RFC-nya. Tapi ini mungkin method yang paling banyak dipake di luar method standar.

Cara Kerja

PURGE adalah method de facto buat cache invalidation di CDN. Konsepnya simpel:

  1. Lo ngirim request PURGE /products/handphone-123 ke CDN
  2. CDN hapus resource itu dari cache edge server
  3. Request berikutnya yang masuk - CDN fetch fresh dari origin
PURGE /products/handphone-123 HTTP/1.1
Host: api.toko-lo.com

Itu aja. Gak perlu purge seluruh cache. Gak perlu nunggu TTL kedaluwarsa. Cuma satu URL, langsung bersih.

Penggunaan Sehari-hari

  • E-commerce - lo update harga produk. Tinggal PURGE URL produk itu di CDN, user langsung lihat harga baru tanpa nunggu cache expire.
  • Content publishing - abis publish artikel atau update halaman berita, PURGE URL-nya di edge. Content baru nyebar dalam hitungan detik.
  • API response update - kalo ada data master (daftar toko, daftar kategori) yang jarang berubah tapi harus real-time pas diupdate.

Siapa yang Support?

PlatformDukungan
VarnishPURGE native - define di VCL: acl purge { "localhost"; }
CloudflarePake header: curl -X PURGE https://zone.com/url - support single URL & multi-URL purge
FastlyPURGE + soft PURGE (invalidate tapi tetap serve stale kalo origin down)
AkamaiPake header PURGE atau CP Code purge via API
Nginx (+ ngx_cache_purge)Module tambahan, enable PURGE buat FastCGI/proxy cache
CDN umumMayoritas implementasi support PURGE sebagai non-standard method

Kelemahan

Gak ada standardisasi - tiap CDN implementasi beda cara validate PURGE:

  • Varnish pake ACL (IP-based)
  • Cloudflare pake API Token di header
  • Fastly pake API key di header

Lo harus sesuaikan client code dengan platform. Tapi semantiknya sama: hapus cache untuk resource tertentu.

Fun Fact

PURGE sebenernya mirip cara kerja HTTP cache headers - tapi beda mekanisme. Kalo lo set Cache-Control: no-cache, itu ngasih tau client/CDN buat revalidate Sebelum pake cache. PURGE itu paksa hapus langsung. Analoginya: no-cache itu “cek dulu ya kalo mau pake”, PURGE itu “buang aja yang lama”.

SEARCH - Kakak Tua QUERY

SEARCH didefinisikan di RFC 5323 tahun 2008 sebagai extension WebDAV. Idenya sama kayak QUERY: method yang safe dan idempotent dengan body. Tapi bedanya - SEARCH pake XML. Makanya kurang populer.

Cara Kerja

SEARCH /api/products HTTP/1.1
Content-Type: application/xml; charset="utf-8"

<?xml version="1.0" encoding="UTF-8"?>
<D:searchrequest xmlns:D="DAV:">
  <D:basicsearch>
    <D:select>
      <D:prop>
        <D:displayname/>
        <D:getcontentlength/>
        <D:getcontenttype/>
      </D:prop>
    </D:select>
    <D:from>
      <D:scope>
        <D:href>/api/products/</D:href>
        <D:depth>0</D:depth>
      </D:scope>
    </D:from>
    <D:where>
      <D:and>
        <D:eq>
          <D:prop><D:getcontenttype/></D:prop>
          <D:literal>image/jpeg</D:literal>
        </D:eq>
        <D:gt>
          <D:prop><D:getcontentlength/></D:prop>
          <D:literal>500000</D:literal>
        </D:gt>
      </D:and>
    </D:where>
  </D:basicsearch>
</D:searchrequest>

Iya, itu buat cari file JPEG yang lebih besar dari 500KB. Di XML. Dengan namespace DAV:.

Penggunaan Sehari-hari

Jujur aja - udah jarang. WebDAV secara umum udah gak populer di web development modern. Tapi SEARCH masih dipake di:

  • Enterprise document management - SharePoint, Alfresco, documentum masih pake WebDAV
  • File server WebDAV - tools kayak Cyberduck, ownCloud punya implementasi WebDAV
  • CALDAV / CARDDAV - report method di ekosistem calendar & contact (iCal, Google Calendar sync)

SEARCH vs QUERY - Bedanya?

AspekSEARCH (RFC 5323)QUERY (RFC 9651)
Standar2008 (WebDAV)2024 (HTTP core)
Body formatXML (wajib)Bebas (JSON, XML, CBOR, dll)
SafeYaYa
IdempotentYaYa
Cache-ableYa (dengan syarat)Ya (via Content-Location)
PenggunaanDokumen enterprise, file serverGeneral API, search, query
AdopsiNicheBaru, prospek bagus

Fun Fact

Banyak yang kira SEARCH udah mati - tapi RFC 9651 justru menyebut SEARCH sebagai “pendahulu QUERY.” Mereka sadar kalo konsep “HTTP method dengan body yang safe dan idempotent” itu berguna dan udah ada yang coba (SEARCH). Yang salah dari SEARCH bukan idenya - tapi keputusan buat paksa pake XML format di era JSON.

Mana yang Pantes Lo Pake?

Pertanyaan real-nya: ini practical gak buat lo? Atau cuma jadi pengetahuan tambahan?

MethodKapan Pake
QUERYAPI yang butuh complex query dengan body (search, filter, bulk read). Relatif baru (2024) - butuh setup khusus di server/framework.
PURGEKalo lo pake CDN dan butuh cache invalidation real-time. Ini paling siap-pakai - support hampir semua CDN besar.
SEARCHHanya kalo lo kerja dengan ekosistem WebDAV (SharePoint, Alfresco). Buat project baru? Pake QUERY aja.

Mau mulai dari mana? PURGE - paling gampang, lo tinggal curl -X PURGE ke URL yang udah di-cache CDN. Praktis langsung kerasa efeknya kalo lo sering ngupdate content dan pusing sama cache expired.

Kalo lo punya API search yang kompleks, coba cek apakah framework lo support QUERY method di route. Kalo belum - taruh di backlog aja. Ini investasi jangka panjang, karena standarnya baru - dan butuh waktu sampe semua framework & proxy support.

Terima kasih sudah meluangkan waktu buat baca artikel ini, semoga ada manfaat yang bisa diambil. 🐾