Dalam desain RESTful API, PUT dan PATCH adalah dua metode HTTP yang digunakan untuk memperbarui sumber daya di server, namun perbedaan antara PUT vs PATCH di REST API terletak pada cara keduanya melakukan pembaruan dan skenario mana yang paling tepat untuk masing-masing metode tersebut. Kedua metode tersebut dirancang untuk mengubah data yang ada, namun memahami perbedaan PUT dan PATCH di REST API dapat membantu pengembang membuat pilihan terbaik berdasarkan sifat pembaruan yang perlu mereka lakukan. Dalam postingan blog ini, kita akan mengeksplorasi perbedaan PUT dan PATCH di REST API, dengan fokus pada perdebatan PATCH vs update REST, kapan harus menggunakan masing-masing, dan memberikan panduan dalam memilih metode yang tepat untuk berbagai kasus penggunaan.
Apa itu PUT di REST API?
Untuk memahami perbedaan antara PUT vs PATCH di REST API, pertama-tama kita perlu mengetahui apa itu PUT. Berdasarkan Bagian 9.6 RFC 2616, metode PUT di REST API meminta agar entitas terlampir disimpan di bawah URI Permintaan yang disediakan.
Jika URI Permintaan mengacu pada sumber daya yang sudah ada, entitas terlampir HARUS dianggap sebagai versi modifikasi dari yang berada di server asal. Jika URI-Permintaan tidak menunjuk ke sumber daya yang ada dan URI tersebut mampu didefinisikan sebagai sumber daya baru oleh agen pengguna yang meminta, server asal dapat membuat sumber daya dengan URI tersebut.
Dengan kata lain, metode PUT digunakan untuk memperbarui seluruh sumber daya di server. Hal ini membuat PUT menjadi pembaruan yang lebih “lengkap”, sering kali digunakan ketika penggantian sumber daya secara penuh diperlukan.
Jadi, PUT paling cocok untuk kasus penggunaan berikut:
- Memperbarui sumber daya yang lengkap (misalnya, memperbarui profil pengguna dengan semua informasi baru).
- Mengganti seluruh item atau catatan.
- Ketika identitas sumber daya sudah jelas, dan datanya perlu disegarkan sepenuhnya.
Dalam sistem seperti Pencarian elastis, 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 di REST API?
Sekarang kita telah membahas PUT di REST API, mari kita lihat apa itu PATCH di REST API dan cara kerjanya sebelum kita membandingkan PUT vs PATCH di REST API. Sebagaimana didefinisikan dalam RFC 5789, metode PATCH di REST API meminta agar serangkaian perubahan yang dijelaskan dalam entitas permintaan diterapkan ke sumber daya yang diidentifikasi oleh Request-URI.
Hal ini selaras dengan perbedaan PUT vs PATCH REST API, di mana Anda hanya mengirim data yang perlu diubah, dan server menerapkan perubahan tersebut ke sumber daya yang ada tanpa mengubah keseluruhan sumber daya. Pengembang sering kali membuat patch untuk mewakili perubahan bertahap ini, memastikan transfer data minimal dan pembaruan yang efisien.
Itu sebabnya metode PATCH di REST API lebih cocok untuk kasus penggunaan berikut:
- Memperbarui hanya sebagian bidang dalam sumber daya (misalnya, mengubah alamat email atau nomor telepon pengguna). Contoh PATCH API dapat melibatkan pengiriman email baru saja, membiarkan kolom lainnya tidak tersentuh.
- Meningkatkan kinerja dengan meminimalkan muatan data.
- Saat Anda ingin memperbarui sumber daya secara bertahap daripada menggantinya sepenuhnya.
- Buat patch untuk merangkum perubahan bidang tertentu, seperti mengubah email pengguna, tanpa memengaruhi data yang tidak terkait.
Untuk platform seperti CMS tanpa kepala yang sering menangani struktur konten yang kompleks, menggunakan PATCH untuk pembaruan yang lebih kecil—seperti memodifikasi satu bidang—dapat mengurangi beban server dan meningkatkan kinerja.
Dengan membahas kedua metode ini, Anda seharusnya memiliki gambaran yang baik tentang apa itu PUT dan PATCH di REST API. Namun, sebelum kita membahas perbedaan antara PUT vs PATCH di REST API, kita perlu membahas tentang Idempotensi dalam kedua metode ini.
Idempotensi Dalam PUT Vs Patch di REST API
Di REST API, idempotensi mengacu pada properti operasi yang, jika diulang beberapa kali dengan masukan yang sama, akan menghasilkan hasil yang sama. Artinya, membuat permintaan yang sama beberapa kali akan memberikan efek yang sama pada server, berapa kali pun permintaan tersebut dijalankan. Hal ini penting untuk memastikan stabilitas dan prediktabilitas dalam API. Tapi apa relevansinya dengan perbedaan PUT dan PATCH di REST API?
Metode PUT dan Idempotensi
Metode PUT di REST API selalu idempoten karena dirancang untuk menggantikan seluruh sumber daya pada URI tertentu dengan data yang disediakan dalam permintaan. Dengan kata lain, jika Anda melakukan permintaan PUT beberapa kali dengan data sumber daya yang sama, hasilnya akan selalu sama.
Mengapa PUT Idempoten? Saat Anda membuat permintaan PUT, pada dasarnya Anda memberi tahu server, “Ini adalah keadaan lengkap dan tepat yang saya inginkan untuk sumber daya ini.” Baik Anda mengeluarkan permintaan PUT sekali atau berkali-kali, sumber daya yang dihasilkan akan selalu sama.
Misalnya, pertimbangkan skenario saat Anda memperbarui alamat email pengguna. Jika Anda membuat permintaan PUT yang sama beberapa kali, hasilnya tidak akan berubah karena sumber daya selalu diganti dengan data yang sama.
Contoh:
| PUT /users/1{“nama pengguna”: “john_doe”,”email”: “[email protected]”} |
Jika Anda mengirimkan permintaan ini beberapa kali, hasilnya akan selalu sama:
| {“nama pengguna”: “john_doe”,”email”: “[email protected]”} |
Sekalipun data pengguna sudah sebesar ini, mengirimkan permintaan lagi tidak mengubah apa pun. Ini menggantikan data dengan data yang sama, sehingga efek permintaan tetap sama terlepas dari berapa kali permintaan tersebut diulang. Hal inilah yang membuat PUT idempoten.
Metode PATCH dan Idempotensi
Sebaliknya, metode PATCH di REST API umumnya juga idempoten, tetapi lebih fleksibel. Saat Anda membuat patch, pastikan operasinya idempoten (misalnya, menetapkan nilai) untuk menghindari efek samping yang tidak diinginkan dari permintaan berulang. Apakah PATCH idempoten tergantung pada operasi dan data yang dimodifikasi.
Mengapa PATCH Idempoten? Untuk permintaan PATCH, idempotensi berarti menerapkan patch yang sama beberapa kali akan memberikan hasil yang sama. Hal ini berlaku selama patch itu sendiri tidak menimbulkan efek samping atau perubahan tambahan ketika diterapkan berulang kali. Jika Anda terus menerapkan patch yang sama dengan data yang sama, hasilnya tidak akan berubah setelah aplikasi pertama.
Misalnya, jika Anda hanya memperbarui email pengguna, mengirimkan permintaan PATCH yang sama berulang kali tidak akan mengubah hasilnya setelah pertama kali, meskipun permintaan tersebut dibuat beberapa kali. Email pengguna akan tetap sama, dan status sumber daya tidak akan berubah.
Contoh API PATCH:
| PATCH /pengguna/1{“email”: “[email protected]”} |
Jika emailnya sudah [email protected], maka penerapan PATCH ini lagi tidak akan menghasilkan perubahan, sehingga menjadi idempoten.
Namun, PATCH juga bisa bersifat non-idempoten dalam beberapa kasus. Misalnya, jika operasi PATCH memodifikasi penghitung atau menambahkan item ke daftar (seperti menambah angka atau menambahkan ke array), penerapan PATCH yang sama secara berulang dapat memberikan hasil yang berbeda. Hal ini akan melanggar sifat idempotensi.
Contoh REST PATCH API non-idempoten:
| PATCH /counter/1{"kenaikan": 1} |
Jika Anda menerapkan PATCH ini berulang kali, penghitungnya akan terus bertambah, menghasilkan nilai yang berbeda setiap saat. Ini bukan idempoten karena hasilnya berubah setiap kali diterapkan.
Sekarang setelah Anda mengetahui hal-hal penting, kita dapat melihat beberapa contoh skenario untuk lebih memahami perbedaan antara PUT vs PATCH di REST API.
Contoh Skenario: PUT vs PATCH di REST API
Terlepas dari teorinya, mari kita lihat perbedaan antara PUT dan PATCH dengan contoh, termasuk operasi idempoten dan non-idempoten.
Skenario 1: Permintaan PUT – Mengganti Seluruh Sumber Daya
Bayangkan sebuah titik akhir API untuk mengelola produk dalam sistem e-niaga. Anda perlu memperbarui semua detail produk, termasuk nama, harga, dan deskripsinya. Ini adalah contoh umum metode HTTP PUT vs PATCH, di mana PUT digunakan untuk menggantikan sumber daya produk lengkap.
Produk Awal:
| DAPATKAN /products/1001{“id”: 1001,”name”: “Laptop”,”price”: 999.99,”description”: “Laptop yang tangguh.”} |
Anda ingin memperbarui harga dan deskripsi produk. Anda mengirim permintaan PUT dengan seluruh sumber daya:
Permintaan PUT:
| PUT /products/1001{“id”: 1001,”name”: “Laptop”,”price”: 899.99,”description”: “Laptop tangguh yang didiskon.”} |
Jika Anda membuat permintaan PUT ini satu atau beberapa kali, hasilnya akan selalu sama. Detail produk akan diperbarui untuk mencerminkan harga dan deskripsi baru, dan hasil yang sama akan terjadi setiap saat. Hal ini memastikan sifat idempoten dari PUT.
Hasil (Setelah Permintaan PUT):
| {“id”: 1001,”name”: “Laptop”,”price”: 899.99,”description”: “Laptop tangguh yang didiskon.”} |
Skenario 2: Permintaan PATCH – Memperbarui Bagian Sumber Daya
Sekarang, mari pertimbangkan permintaan PATCH untuk memperbarui hanya sebagian detail produk, seperti deskripsi. Contoh PATCH API: Jika Anda ingin mengubah deskripsi produk tetapi tidak ingin mengubah harganya, PATCH adalah pilihan yang lebih baik. Untuk menerapkan hal ini, Anda akan membuat patch yang hanya berisi bidang yang memerlukan modifikasi, seperti deskripsi dalam contoh API REST PATCH ini.
Produk Awal:
| DAPATKAN /products/1001{“id”: 1001,”name”: “Laptop”,”price”: 999.99,”description”: “Laptop yang tangguh.”} |
Permintaan PATCH:
| PATCH /products/1001{“description”: “Laptop yang ringan dan kuat.”} |
Saat Anda mengirimkan permintaan PATCH ini, hanya kolom deskripsi yang akan diperbarui. Jika Anda mengirimkan permintaan PATCH yang sama beberapa kali, deskripsinya tidak akan berubah setelah pembaruan pertama, sehingga membuat permintaan tersebut menjadi idempoten.
Hasil (Setelah Permintaan PATCH):
| {“id”: 1001,”name”: “Laptop”,”price”: 999.99,”description”: “Laptop yang ringan dan bertenaga.”} |
Jika Anda menerapkan PATCH yang sama lagi, deskripsi produk akan tetap sama seperti setelah PATCH pertama. Hasilnya konsisten, yang menjadikan PATCH idempoten dalam skenario ini.
Skenario 3: Permintaan PATCH – Operasi Non-idempoten
Mari kita lihat operasi PATCH non-idempoten. Misalkan ada titik akhir untuk saldo dompet pengguna, dan Anda ingin menambah saldo. Contoh perbedaan antara PUT dan PATCH dapat diilustrasikan di sini: PATCH akan menambahkan nilai ke saldo setiap kali
Dompet Awal:
| DAPATKAN /users/1/wallet{“id”: 1,”saldo”: 100,00} |
Permintaan PATCH:
| PATCH /pengguna/1/dompet{"kenaikan": 50,00} |
Permintaan PATCH ini akan meningkatkan saldo dompet sebesar $50. Jika Anda mengirimkan permintaan PATCH ini beberapa kali, saldo akan terus bertambah pada setiap PATCH, sehingga menghasilkan hasil yang berbeda setiap kali. Ini bukan idempoten karena menerapkan PATCH yang sama berulang kali akan menghasilkan hasil yang berbeda.
Hasil (Setelah Permintaan PATCH Pertama):
| {“id”: 1,”saldo”: 150,00} |
Hasil (Setelah Permintaan PATCH Kedua):
| {“id”: 1,”saldo”: 200,00} |
Di sini, PATCH tidak idempoten karena permintaan berulang dengan data yang sama menghasilkan hasil yang berbeda.
Rekap: Perbedaan Utama Antara PUT Vs PATCH Di REST API
Perbedaan utama antara PUT vs PATCH di REST API adalah cara mereka menangani pembaruan. PUT menggantikan seluruh sumber daya, sehingga setiap bidang yang hilang akan dihapus, yang dapat menyebabkan hilangnya data. Inilah sebabnya pengembang membuat patch untuk pembaruan parsial—untuk menghindari penimpaan kolom yang tidak diubah dan menjaga integritas data.
Hal ini membuat PATCH lebih efisien untuk pembaruan parsial. Contoh PATCH API adalah Jika Anda hanya ingin memperbarui email pengguna, membuat patch hanya akan mengirimkan kolom email, tidak seperti permintaan PUT yang memerlukan seluruh data pengguna.
Dengan PUT, diperlukan muatan data penuh. Ini berarti setiap kolom harus dikirim, dan kolom yang hilang akan dihapus. Namun PATCH hanya mengirimkan kolom yang perlu diperbarui, sehingga lebih efisien, terutama untuk sumber daya besar dengan perubahan minimal. Metode PATCH di REST API memungkinkan permintaan yang lebih fokus dan lebih kecil, sehingga mengurangi transfer data.
PUT dan PATCH keduanya idempoten. Artinya, mengulangi permintaan yang sama akan menghasilkan hasil yang sama. Namun, PUT lebih dapat diprediksi karena menggantikan seluruh sumber daya. PATCH, ketika digunakan untuk memodifikasi kolom tertentu saja, mungkin memberikan hasil yang berbeda tergantung pada bagaimana pembaruan ditangani oleh server.
Misalnya, jika PATCH menambah penghitung, permintaan berulang dapat memberikan hasil yang berbeda. Meskipun demikian, operasi PATCH API juga dapat dirancang menjadi idempoten.
Kesimpulannya, perbedaan PUT dan PATCH di REST API terletak pada sifat pembaruannya: PATCH untuk perubahan sebagian, sedangkan PUT untuk penggantian sumber daya sepenuhnya. Keduanya idempoten, namun PATCH bisa lebih kompleks.
Pikiran Terakhir
Baik PUT dan PATCH adalah metode HTTP dasar dalam desain REST API, namun keduanya memiliki tujuan yang berbeda, yang merupakan inti dari perbedaan PUT dan PATCH dalam REST API. Anda dapat meningkatkan efisiensi, kejelasan, dan fungsionalitas API secara signifikan dengan memahami perbedaan antara PUT dan PATCH menggunakan contoh yang kami bahas sebelumnya di artikel ini. Dengan memilih metode yang tepat (PATCH vs update REST) berdasarkan kasus penggunaan, Anda dapat membuat API lebih efisien, mudah dikelola, dan ramah pengguna. Selalu pertimbangkan sifat pembaruan—baik penuh atau sebagian—bersama dengan dampaknya terhadap kinerja dan integritas data, dan pilih metode yang paling sesuai dengan kebutuhan Anda.
