Dalam desain API yang REST, PUT dan PATCH adalah dua metode HTTP yang digunakan untuk memperbarui resource di server. Namun, perbedaan PUT vs PATCH dalam REST API terletak pada cara keduanya melakukan pembaruan dan skenario di mana masing-masing paling tepat digunakan. Kedua metode dirancang untuk memodifikasi data yang sudah ada, dan memahami perbedaan PUT vs PATCH dalam REST API dapat membantu developer membuat pilihan terbaik sesuai dengan sifat pembaruan yang perlu dilakukan. Dalam artikel ini, kita akan membahas perbedaan PUT dan PATCH dalam REST API, mengulas perdebatan PATCH vs update REST, kapan menggunakan masing-masing metode, serta panduan memilih metode yang tepat untuk berbagai kasus penggunaan.
Apa itu PUT dalam REST API?
Untuk memahami perbedaan PUT vs PATCH dalam REST API, pertama-tama kita perlu memahami apa itu PUT. Berdasarkan Bagian 9.6 RFC 2616, metode PUT dalam REST API meminta agar entitas yang disertakan disimpan di bawah Request-URI yang diberikan.
Jika Request-URI merujuk ke resource yang sudah ada, entitas yang disertakan HARUS dianggap sebagai versi yang diperbarui dari resource yang ada di server asal. Jika Request-URI tidak mengarah ke resource yang sudah ada, dan URI tersebut dapat didefinisikan sebagai resource baru oleh user agent yang meminta, server asal dapat membuat resource dengan URI tersebut.
Dengan kata lain, metode PUT digunakan untuk memperbarui seluruh resource di server. Ini menjadikan PUT sebagai pembaruan yang lebih "menyeluruh", yang umumnya dipakai ketika seluruh resource perlu diganti.
Jadi, PUT paling tepat digunakan untuk kasus-kasus berikut:
- Memperbarui resource secara lengkap (misalnya, memperbarui profil pengguna dengan semua informasi baru).
- Mengganti seluruh item atau record.
- Ketika identitas resource sudah jelas dan datanya perlu diperbarui sepenuhnya.
Dalam sistem seperti Elasticsearch, operasi idempoten diperlukan untuk menjamin konsistensi data. Misalnya, memperbarui dokumen di Elasticsearch menggunakan PUT memastikan bahwa permintaan yang sama dapat diulang tanpa efek samping yang tidak diinginkan.
Apa itu PATCH dalam REST API?
Setelah membahas PUT dalam REST API, mari kita lihat apa itu PATCH dalam REST API dan cara kerjanya sebelum membandingkan PUT vs PATCH dalam REST API. Sebagaimana didefinisikan dalam RFC 5789, metode PATCH dalam REST API meminta agar sekumpulan perubahan yang dijelaskan dalam entitas permintaan diterapkan pada resource yang diidentifikasi oleh Request-URI.
Ini sejalan dengan perbedaan PUT vs PATCH dalam REST API, di mana Anda hanya mengirimkan data yang perlu diubah, dan server menerapkan perubahan tersebut pada resource yang ada tanpa mengubah resource secara keseluruhan. Developer sering membuat patch untuk merepresentasikan perubahan bertahap ini, sehingga transfer data tetap minimal dan pembaruan menjadi lebih efisien.
Itulah mengapa metode PATCH dalam REST API lebih cocok untuk kasus-kasus berikut:
- Memperbarui hanya sebagian field dalam resource (misalnya, mengubah alamat email atau nomor telepon pengguna). Contoh PATCH API bisa melibatkan pengiriman email baru saja, tanpa menyentuh field lainnya.
- Meningkatkan performa dengan meminimalkan ukuran payload data.
- Ketika Anda ingin memperbarui resource secara bertahap, bukan menggantinya sepenuhnya.
- Buat patch untuk merangkum perubahan field tertentu, seperti mengubah email pengguna, tanpa memengaruhi data yang tidak terkait.
Untuk platform seperti CMS headless yang sering menangani struktur konten yang kompleks, menggunakan PATCH untuk pembaruan kecil - seperti mengubah satu field - dapat mengurangi beban server dan meningkatkan performa.
Dengan dua metode ini tercakup, Anda seharusnya sudah punya gambaran yang cukup tentang apa itu PUT dan PATCH dalam REST API. Namun, sebelum kita masuk ke perbedaan PUT vs PATCH dalam REST API, kita perlu membahas Idempoten pada kedua metode ini.
Idempotence dalam PUT vs PATCH di REST API
Dalam REST API, idempoten mengacu pada sifat suatu operasi yang, ketika diulang beberapa kali dengan input yang sama, menghasilkan hasil yang sama. Ini berarti membuat permintaan yang sama beberapa kali seharusnya memberikan efek yang sama pada server, terlepas dari berapa kali permintaan itu dieksekusi. Hal ini penting untuk menjaga stabilitas dan keterpreduksian dalam API. Tapi bagaimana kaitannya dengan perbedaan PUT dan PATCH dalam REST API?
Metode PUT dan Idempotence
Metode PUT dalam REST API selalu idempoten karena dirancang untuk mengganti seluruh resource pada URI tertentu dengan data yang diberikan dalam permintaan. Dengan kata lain, jika Anda melakukan permintaan PUT beberapa kali dengan data resource yang sama, hasilnya akan selalu sama.
Mengapa PUT Bersifat Idempoten? Ketika Anda membuat permintaan PUT, Anda pada dasarnya memberi tahu server: "Ini adalah kondisi lengkap dan tepat yang saya inginkan untuk resource ini." Baik Anda mengirim permintaan PUT sekali maupun berkali-kali, resource yang dihasilkan akan selalu identik.
Misalnya, pertimbangkan skenario di mana Anda memperbarui alamat email pengguna. Jika Anda membuat permintaan PUT yang sama beberapa kali, hasilnya tidak akan berubah karena resource diganti dengan data yang sama setiap kali.
Contoh:
| PUT /users/1{"username": "john_doe","email": "[email protected]"} |
Jika Anda mengirim permintaan ini beberapa kali, hasilnya akan selalu sama:
| {"username": "john_doe","email": "[email protected]"} |
Meskipun data pengguna sudah sama, mengirim request yang sama sekali lagi tidak mengubah apa pun. Data diganti dengan data yang sama, sehingga efek request tetap konsisten tidak peduli berapa kali diulang. Inilah yang membuat PUT bersifat idempoten.
Metode PATCH dan Idempotence
Metode PATCH dalam REST API, di sisi lain, umumnya juga bersifat idempoten, tetapi dengan fleksibilitas lebih tinggi. Saat membuat patch, pastikan setiap operasi bersifat idempoten (misalnya, menetapkan suatu nilai) agar tidak menimbulkan efek samping yang tidak diinginkan akibat request berulang. Apakah PATCH bersifat idempoten bergantung pada operasi dan data yang dimodifikasi.
Mengapa PATCH Bersifat Idempoten? Pada request PATCH, idempoten berarti menerapkan patch yang sama berkali-kali akan menghasilkan hasil yang sama. Hal ini berlaku selama patch tersebut tidak menimbulkan efek samping atau perubahan tambahan saat diterapkan berulang kali. Jika Anda terus menerapkan patch yang sama dengan data yang sama, hasilnya tidak akan berubah setelah penerapan pertama.
Misalnya, jika Anda hanya memperbarui email pengguna, mengirim request PATCH yang sama berulang kali tidak akan mengubah hasilnya setelah pengiriman pertama, meskipun request dikirim beberapa kali. Email pengguna akan tetap sama, dan status resource tidak akan berubah.
Contoh PATCH API:
| PATCH /users/1{"email": "[email protected]"} |
Jika email sudah [email protected], menerapkan PATCH ini lagi tidak akan menghasilkan perubahan apa pun, sehingga bersifat idempoten.
Namun, PATCH juga bisa bersifat non-idempoten dalam beberapa kasus. Misalnya, jika operasi PATCH memodifikasi counter atau menambahkan item ke sebuah list (seperti menambah angka atau menambahkan elemen ke array), penerapan PATCH yang sama secara berulang dapat menghasilkan hasil yang berbeda. Ini melanggar sifat idempoten.
Contoh PATCH API REST Non-Idempoten:
| PATCH /counter/1{"increment": 1} |
Jika Anda menerapkan PATCH ini berulang kali, counter akan terus bertambah dan menghasilkan nilai berbeda setiap kali. Ini tidak idempoten karena hasilnya berubah pada setiap penerapan.
Setelah memahami dasarnya, mari kita lihat beberapa skenario contoh untuk memahami lebih jauh perbedaan antara PUT dan PATCH dalam REST API.
Contoh Skenario: PUT vs PATCH dalam REST API
Cukup teorinya, sekarang mari kita lihat perbedaan antara PUT dan PATCH melalui contoh nyata, termasuk operasi idempoten maupun non-idempoten.
Skenario 1: Request PUT - Mengganti Seluruh Resource
Bayangkan sebuah endpoint API untuk mengelola produk dalam sistem e-commerce. Anda perlu memperbarui semua detail produk, termasuk nama, harga, dan deskripsinya. Ini adalah contoh umum perbandingan metode HTTP PUT vs PATCH, di mana PUT digunakan untuk mengganti seluruh resource produk.
Produk Awal
| GET /products/1001{"id": 1001,"name": "Laptop","price": 999.99,"description": "A powerful laptop."} |
Anda ingin memperbarui harga dan deskripsi produk. Kirimkan request PUT dengan seluruh data resource:
Permintaan PUT:
| PUT /products/1001{"id": 1001,"name": "Laptop","price": 899.99,"description": "A discounted powerful laptop."} |
Baik dikirim sekali maupun berkali-kali, request PUT ini akan selalu menghasilkan hasil yang sama. Detail produk akan diperbarui sesuai harga dan deskripsi baru, dan hasil yang sama akan muncul setiap kali. Ini menegaskan sifat idempoten dari PUT.
Hasil (Setelah Request PUT):
| {"id": 1001,"name": "Laptop","price": 899.99,"description": "A discounted powerful laptop."} |
Skenario 2: Request PATCH - Memperbarui Sebagian Resource
Sekarang, mari kita perhatikan request PATCH untuk memperbarui hanya sebagian detail produk, seperti deskripsinya. Contoh PATCH API: Jika Anda ingin mengubah deskripsi produk tanpa menyentuh harganya, PATCH adalah pilihan yang tepat. Untuk melakukannya, buat patch yang hanya berisi field yang perlu diubah, seperti deskripsi dalam contoh PATCH API REST ini.
Produk Awal
| GET /products/1001{"id": 1001,"name": "Laptop","price": 999.99,"description": "A powerful laptop."} |
Permintaan PATCH:
| PATCH /products/1001{"description": "A lightweight, powerful laptop."} |
Saat kamu mengirim PATCH request ini, hanya field description yang akan diperbarui. Jika kamu mengirim PATCH request yang sama berkali-kali, description tidak akan berubah setelah pembaruan pertama, sehingga request ini bersifat idempotent.
Hasil (Setelah PATCH Request):
| {"id": 1001,"name": "Laptop","price": 999.99,"description": "A lightweight, powerful laptop."} |
Jika kamu mengirim PATCH yang sama lagi, deskripsi produk akan tetap sama seperti setelah PATCH pertama. Hasilnya konsisten, yang membuat PATCH bersifat idempotent dalam skenario ini.
Skenario 3: PATCH Request – Operasi Non-idempotent
Mari kita lihat operasi PATCH yang bersifat non-idempotent. Misalkan ada endpoint untuk saldo dompet pengguna, dan kamu ingin menambah saldo tersebut. Perbedaan antara PUT dan PATCH dapat diilustrasikan di sini: PATCH akan menambahkan nilai ke saldo setiap kali dipanggil.
Dompet Awal:
| GET /users/1/wallet{"id": 1,"balance": 100.00} |
Permintaan PATCH:
| PATCH /users/1/wallet{"increment": 50.00} |
PATCH request ini akan menambah saldo dompet sebesar $50. Jika kamu mengirim PATCH request yang sama berkali-kali, saldo akan terus bertambah setiap kali PATCH dikirim, menghasilkan nilai yang berbeda setiap saat. Ini bersifat non-idempotent karena mengirim PATCH yang sama berulang kali menghasilkan hasil yang berbeda.
Hasil (Setelah PATCH Request Pertama):
| {"id": 1,"balance": 150.00} |
Hasil (Setelah PATCH Request Kedua):
| {"id": 1,"balance": 200.00} |
Di sini, PATCH tidak bersifat idempotent karena request yang sama dengan data yang sama menghasilkan hasil yang berbeda.
Rangkuman: Perbedaan Utama antara PUT dan PATCH dalam REST API
Perbedaan utama antara PUT dan PATCH dalam REST API adalah cara keduanya menangani pembaruan. PUT mengganti seluruh resource, sehingga field yang tidak disertakan akan terhapus, yang dapat menyebabkan kehilangan data. Itulah mengapa developer menggunakan patch untuk pembaruan parsial — untuk menghindari penimpaan field yang tidak berubah dan menjaga integritas data.
Hal ini membuat PATCH lebih efisien untuk pembaruan parsial. Contoh PATCH API: jika kamu hanya ingin memperbarui email pengguna, patch hanya akan mengirim field email, berbeda dengan PUT request yang mengharuskan pengiriman seluruh data pengguna.
Dengan PUT, seluruh payload data wajib disertakan. Artinya setiap field harus dikirim, dan field yang tidak disertakan akan terhapus. PATCH, sebaliknya, hanya mengirim field yang perlu diperbarui, sehingga lebih efisien, terutama untuk resource besar dengan perubahan kecil. Method PATCH dalam REST API memungkinkan request yang lebih terfokus dan ringkas, sehingga mengurangi transfer data.
PUT maupun PATCH keduanya bersifat idempotent. Artinya, mengulangi request yang sama akan menghasilkan hasil yang sama. Namun, PUT lebih mudah diprediksi karena mengganti seluruh resource. PATCH, saat digunakan untuk mengubah hanya field tertentu, bisa menghasilkan hasil yang berbeda tergantung pada cara server menangani pembaruan tersebut.
Misalnya, jika sebuah PATCH menginkremen sebuah counter, request yang diulang bisa menghasilkan hasil yang berbeda. Meski begitu, operasi PATCH API dapat dirancang agar bersifat idempotent.
Kesimpulannya, perbedaan PUT dan PATCH dalam REST API bermuara pada jenis pembaruannya: PATCH untuk perubahan parsial, sedangkan PUT untuk penggantian resource secara keseluruhan. Keduanya bersifat idempotent, tetapi PATCH bisa lebih kompleks.
Pemikiran Akhir
PUT dan PATCH keduanya adalah method HTTP fundamental dalam desain REST API, namun keduanya melayani tujuan yang berbeda — itulah inti dari perbedaan PUT dan PATCH dalam REST API. Kamu dapat meningkatkan efisiensi, kejelasan, dan fungsionalitas API kamu secara signifikan dengan memahami perbedaan antara PUT dan PATCH melalui contoh-contoh yang telah dibahas sebelumnya dalam artikel ini. Dengan memilih method yang tepat (PATCH vs update REST) sesuai kebutuhan, kamu dapat membuat API kamu lebih efisien, mudah dipelihara, dan ramah pengguna. Selalu pertimbangkan sifat pembaruan — apakah bersifat penuh atau parsial — beserta dampaknya terhadap performa dan integritas data, lalu pilih method yang paling sesuai dengan kebutuhanmu.
