Kode Status 406 Not Acceptable: Penyebab dan Cara Mengatasi

Dalam kosakata kaya kode status HTTP, beberapa kode lebih menonjol daripada yang lain, sementara beberapa lainnya secara diam-diam menjalankan peran penting dalam memastikan komunikasi klien-server yang lancar. Kode status 406 Not Acceptable adalah salah satu pahlawan yang kurang dikenal tersebut. Mungkin tidak muncul sesering 404 atau 500 yang populer, tetapi memahami tujuannya dapat secara dramatis meningkatkan pemahaman Anda tentang negosiasi konten dan meningkatkan fleksibilitas aplikasi web dan API Anda.

Kode status 406 Not Acceptable dapat terasa seperti pesan samar dari server Anda. Tetapi begitu Anda memahami artinya, itu menjadi sinyal kuat yang membantu Anda merancang API yang lebih bersih, lebih dapat diprediksi, dan lebih ramah pengguna.

Kode status ini merepresentasikan kegagalan komunikasi dalam proses negosiasi konten yang canggih, di mana klien dan server menyepakati format terbaik untuk pertukaran data.

Dalam postingan blog ini, kita akan menyelami lebih dalam apa arti HTTP 406 Not Acceptable, mengapa itu terjadi, bagaimana negosiasi konten memengaruhinya, dan bagaimana Anda, sebagai pengembang atau konsumen API, dapat menanganinya secara efektif. Debugging kesalahan aneh seperti 406 Not Acceptable bisa memakan waktu tanpa alat yang tepat. Itulah mengapa saya merekomendasikan Apidog. Ini adalah platform API all-in-one gratis yang memungkinkan Anda merancang, membuat mock, menguji, mendebug, dan mendokumentasikan API dengan mudah sehingga Anda akan tahu persis mengapa Anda mendapatkan 406 dan cara memperbaikinya dengan cepat.

💡

Jika Anda ingin menjelajahi dan menguji API dengan mulus termasuk respons dengan status 406, unduh Apidog secara gratis. Apidog adalah alat pengujian dan dokumentasi API penting yang membuat investigasi kode status HTTP seperti 406 menjadi mudah dan efektif.

button

Sekarang, mari kita jelajahi dunia negosiasi konten dan kode status HTTP 406 Not Acceptable.

Masalahnya: Setiap Orang Menginginkan Data dengan Cara Mereka Sendiri

Di masa-masa awal web, server biasanya menawarkan satu format untuk sumber daya mereka, biasanya HTML. Tetapi seiring perkembangan web, klien yang berbeda muncul dengan kebutuhan yang berbeda:

Peramban web menginginkan HTML
Aplikasi seluler menginginkan JSON
Layanan lain mungkin menginginkan XML
Beberapa klien mungkin membutuhkan ekspor PDF atau CSV

Kode status 406 ada karena terkadang klien meminta format yang tidak dapat disediakan oleh server untuk sumber daya tertentu.

Apa Sebenarnya Arti HTTP 406 Not Acceptable?

Kode status 406 Not Acceptable menunjukkan bahwa server tidak dapat menghasilkan respons yang cocok dengan daftar nilai yang dapat diterima yang ditentukan dalam header negosiasi konten proaktif permintaan, dan bahwa server tidak bersedia menyediakan representasi default.

Secara lebih sederhana: "Anda telah memberi tahu saya format apa saja yang akan Anda terima, dan saya tidak dapat menyediakan sumber daya dalam salah satu format tersebut."

Respons 406 yang tepat harus menyertakan informasi tentang format apa yang dapat disediakan server untuk sumber daya yang diminta. Ini biasanya dilakukan dengan header atau di badan respons.

Berikut adalah tampilan respons 406:

HTTP/1.1 406 Not AcceptableContent-Type: text/htmlVary: Accept
<html><head><title>406 Not Acceptable</title></head><body><h1>Not Acceptable</h1><p>Sumber daya ini tersedia dalam format berikut:</p><ul><li>application/json</li><li>application/xml</li></ul></body></html>

Untuk API, lebih membantu untuk mengembalikan respons terstruktur:

HTTP/1.1 406 Not AcceptableContent-Type: application/jsonVary: Accept
{
  "error": "not_acceptable",
  "message": "Sumber daya yang diminta tidak tersedia dalam format yang diminta.",
  "available_formats": [
    "application/json",
    "application/xml"
  ]
}

Ini bukan tentang apakah permintaan itu valid. Ini tentang apakah jenis responsnya dapat diterima.

Keajaiban Negosiasi Konten: Cara Kerja Header Accept

Untuk memahami 406, kita perlu memahami bagaimana klien memberi tahu server format apa yang mereka sukai. Ini terjadi melalui header Accept.

Header Accept dalam Tindakan

Ketika klien membuat permintaan, ia dapat menentukan jenis konten apa yang dapat ditanganinya dan mana yang disukainya:

Contoh sederhana:

GET /api/users/123 HTTP/1.1Accept: application/json

Ini mengatakan: "Saya ingin data pengguna, dan saya hanya mengerti JSON."

Contoh yang lebih canggih:

GET /api/users/123 HTTP/1.1Accept: application/json, text/html;q=0.9, application/xml;q=0.8

Ini mengatakan: "Saya lebih suka JSON, tetapi saya juga dapat menangani HTML (dengan preferensi 90%) dan XML (dengan preferensi 80%)."

Parameter q (nilai kualitas) berkisar dari 0 hingga 1, dengan 1 menjadi yang paling disukai.

Ketika Negosiasi Gagal

Kesalahan 406 terjadi ketika server melihat header Accept dan menyadari:

Ia memiliki sumber daya yang diinginkan klien
Ia tidak dapat menyediakannya dalam format apa pun yang ditentukan klien
Ia tidak bersedia mengirim format default (seperti mengirim JSON ke klien yang hanya menerima XML)

Bagaimana 406 Not Acceptable Cocok dalam Negosiasi Konten?

Ketika klien mengirim permintaan HTTP termasuk header Accept yang menentukan jenis media yang dapat diterima (misalnya, hanya meminta respons JSON), server akan mencoba mengirimkan konten sesuai dengan itu.

Jika server tidak dapat menyediakan konten yang dapat diterima yang sesuai dengan kriteria, ia merespons dengan:

textHTTP/1.1 406 Not Acceptable Content-Type: text/html

Pada titik ini, itu berarti server menolak permintaan karena tidak ada representasi konten yang tersedia yang cocok dengan preferensi klien.

Mengapa Server Mengembalikan 406 Daripada 200 OK

Anda mungkin berpikir: mengapa tidak mengembalikan sesuatu saja, meskipun itu bukan format yang disukai?

Inilah mengapa server mengembalikan 406:

Untuk menegakkan aturan negosiasi konten yang ketat.
Untuk mencegah pengiriman data dalam format yang secara eksplisit dikatakan klien tidak dapat diterima.
Untuk membuat debugging lebih mudah bagi pengembang dengan memberi sinyal header Accept yang tidak cocok.

Penyebab Umum Respons 406

Berikut adalah beberapa alasan umum Anda akan melihat 406 Not Acceptable:

Header Accept yang tidak cocok → Klien meminta application/xml tetapi server hanya mendukung application/json.
Klien API yang usang → Menggunakan SDK lama yang mengharapkan format respons yang berbeda.
Konfigurasi server yang tidak tepat → Negosiasi konten tidak diatur dengan benar.
Keanehan kerangka kerja → Beberapa kerangka kerja (seperti Django atau Rails) memberlakukan penanganan Accept yang ketat.
Penanganan kesalahan kustom yang salah → Filter yang terlalu ketat pada format respons.

Skenario Dunia Nyata yang Memicu Kesalahan 406

1. Konflik Pembuatan Versi API

Bayangkan sebuah API yang hanya menyajikan JSON di v2-nya, tetapi klien masih mengharapkan XML dari v1:

GET /v2/products/456 HTTP/1.1Accept: application/xmlHTTP/1.1 406 Not AcceptableContent-Type: application/json
{
  "error": "Versi API ini hanya mendukung JSON",
  "available_formats": ["application/json"]
}

2. Konfigurasi Klien yang Terlalu Restriktif

Aplikasi seluler mungkin dikodekan secara keras untuk hanya menerima JSON, tetapi menemukan server yang hanya menyajikan sumber daya tertentu sebagai XML:

GET /reports/quarterly-sales HTTP/1.1Accept: application/jsonHTTP/1.1 406 Not Acceptable

(Laporan mungkin hanya tersedia sebagai CSV atau PDF)

3. Kegagalan Default yang Hilang

Beberapa server dikonfigurasi untuk ketat tentang negosiasi konten dan menolak untuk menebak format apa yang akan dikembalikan ketika negosiasi gagal.

Bagaimana Server Biasanya Menangani 406?

Menariknya, beberapa server mengabaikan negosiasi konten yang ketat dan kembali ke respons default daripada merespons dengan 406.

Namun, API RESTful yang ketat atau layanan yang menekankan komunikasi yang tepat mungkin mengembalikan 406 ketika persyaratan klien tidak dapat dipenuhi.

406 Not Acceptable vs Kode Status Terkait

Untuk mengklarifikasi peran 406, mari kita lihat status HTTP terkait:

Kode Status	Arti	Kapan Digunakan
400 Bad Request	Sintaks yang salah atau permintaan tidak valid	Permintaan tidak dapat dipahami
406 Not Acceptable	Permintaan valid tetapi server tidak dapat memenuhi header accept	Kegagalan negosiasi konten
415 Unsupported Media Type	Server tidak dapat memproses jenis konten yang dikirimkan oleh klien	Jenis media badan permintaan tidak valid
Perbedaan 406 vs 415	406 berkaitan dengan jenis respons, 415 berkaitan dengan jenis badan permintaan	—

Bagaimana Klien Seharusnya Menangani Respons 406?

Klien yang menerima 406 harus:

Memeriksa header negosiasi konten yang mereka kirim.
Memodifikasi header Accept untuk menyertakan jenis media yang lebih luas.
Menerapkan mekanisme fallback untuk meminta format default (misalnya, /*).
Menghormati kemampuan server dan membatasi permintaan sesuai dengan itu.
Menyediakan pesan yang ramah pengguna jika jenis konten tertentu tidak dapat disajikan.

Apa yang Dapat Dilakukan Pengembang untuk Menghindari atau Menangani 406?

Menawarkan beberapa representasi konten (JSON, XML, HTML) jika memungkinkan.
Menerapkan logika negosiasi sisi server untuk kembali dengan anggun daripada menolak.
Mendokumentasikan jenis media yang didukung dengan jelas untuk konsumen API.
Mencatat respons 406 untuk mengidentifikasi ketidakcocokan atau masalah klien.
Menggunakan pustaka atau kerangka kerja dengan dukungan negosiasi konten bawaan.

Halaman dan Pesan Kesalahan 406 Kustom

Untuk situs web dan API, menyajikan respons kesalahan 406 yang bermakna dan membantu meningkatkan pengalaman pengembang dan pengguna:

Sertakan saran tentang jenis konten yang didukung.
Sediakan tautan atau contoh untuk penggunaan yang benar.
Gunakan bahasa yang jelas dalam pesan kesalahan.
Menata gaya halaman kesalahan yang konsisten dengan branding situs.

Menguji Negosiasi Konten dengan Apidog

Menguji bagaimana API Anda menangani header Accept yang berbeda sangat penting untuk membangun aplikasi yang kuat. Apidog membuat proses ini mudah dan efisien.

Dengan Apidog, Anda dapat:

Memodifikasi Header dengan Mudah: Dengan cepat menambahkan dan memodifikasi header Accept untuk menguji bagaimana server Anda merespons permintaan jenis konten yang berbeda.
Menguji Berbagai Format: Membuat koleksi tes untuk endpoint yang sama dengan header Accept yang berbeda (JSON, XML, HTML) untuk memastikan cakupan yang komprehensif.
Memvalidasi Respons 406: Dengan sengaja mengirim header Accept yang restriktif untuk memverifikasi bahwa server Anda mengembalikan respons 406 yang tepat dengan informasi kesalahan yang membantu.
Mengotomatiskan Tes Negosiasi Konten: Membuat rangkaian tes yang secara otomatis memverifikasi API Anda menangani berbagai permintaan jenis konten dengan benar dan mengembalikan kode status yang sesuai.
Mendebug Skenario Kompleks: Menggunakan pencatatan terperinci Apidog untuk memahami dengan tepat mengapa kesalahan 406 terjadi dan format apa yang sebenarnya didukung server.

button

Pendekatan sistematis ini memastikan API Anda dapat menangani klien dengan persyaratan format yang berbeda dengan anggun. Singkatnya: alih-alih meraba-raba dalam kegelapan, Anda tahu persis apa yang dapat diterima. Unduh Apidog secara gratis dan tingkatkan produktivitas Anda dalam memecahkan masalah negosiasi konten dan skenario 406.

Praktik Terbaik untuk Menangani Kesalahan 406

Untuk Pengembang Server:

Sediakan Informasi Kesalahan yang Membantu: Saat mengembalikan 406, selalu sertakan informasi tentang format apa yang Anda dukung. Ini membantu pengembang klien memperbaiki permintaan mereka.
Gunakan Header Vary: Sertakan header Vary: Accept dalam respons Anda untuk menunjukkan bahwa konten respons bervariasi berdasarkan nilai header Accept. Ini membantu sistem caching bekerja dengan benar.
Pertimbangkan Perilaku Default: Meskipun spesifikasi HTTP memungkinkan server untuk mengembalikan representasi default, banyak API modern memilih untuk ketat dan mengembalikan 406 untuk memaksa klien untuk eksplisit tentang persyaratan mereka.
Dokumentasikan Format yang Didukung: Dokumentasikan dengan jelas jenis konten apa yang didukung API Anda untuk setiap endpoint.

Untuk Pengembang Klien:

Bersikap Fleksibel dalam Header Accept: Kecuali Anda memiliki alasan khusus, sertakan beberapa format dalam header Accept Anda dengan nilai kualitas yang sesuai.
Tangani 406 dengan Anggun: Ketika Anda menerima 406, periksa respons untuk format yang tersedia dan sesuaikan permintaan Anda atau tampilkan pesan kesalahan yang membantu kepada pengguna.
Miliki Logika Fallback: Pertimbangkan untuk memiliki logika fallback yang dapat menangani format yang berbeda jika format pilihan utama Anda tidak tersedia.

Pahlawan Tak Terlihat dalam Negosiasi Konten

Header Vary sangat penting untuk perilaku caching yang tepat ketika negosiasi konten terlibat. Ketika server menyertakan Vary: Accept dalam responsnya, itu memberi tahu cache bahwa konten respons bergantung pada nilai header Accept.

Ini mencegah cache secara tidak benar menyajikan respons JSON kepada klien yang meminta XML, atau sebaliknya.

Dampak Respons 406 pada SEO

Secara umum, 406 tidak terlalu memengaruhi SEO karena mesin pencari biasanya menangani negosiasi konten dengan kuat dan lebih menyukai respons yang valid. Namun, API atau situs web yang salah konfigurasi yang sering mengembalikan 406 dapat membuat perayap atau pengguna frustrasi.

Desain API Modern dan 406

Dalam desain API RESTful modern, penggunaan 406 telah berkembang:

Banyak API hanya JSON dan tidak peduli dengan negosiasi konten, membuat 406 jarang terjadi.
Pembuatan versi melalui URL (misalnya, /v1/, /v2/) menjadi lebih umum daripada negosiasi konten untuk perubahan format.
API Hypermedia (HATEOAS) sering menggunakan negosiasi konten untuk menyajikan representasi yang berbeda dari sumber daya yang sama.

Namun, 406 tetap relevan untuk:

API yang menyajikan beberapa format data
Sistem manajemen konten yang dapat mengeluarkan HTML, JSON, dan XML
Layanan yang menyediakan ekspor data dalam berbagai format

Memecahkan Masalah Kesalahan 406

Periksa header permintaan klien untuk nilai Accept yang restriktif.
Tinjau format yang didukung server dan logika negosiasi.
Gunakan alat seperti Apidog untuk bereksperimen dengan kombinasi header yang berbeda.
Sesuaikan konfigurasi klien atau server untuk memperluas opsi konten yang diterima.

Pertimbangan Keamanan Sekitar 406

Mencegah server membocorkan format yang tidak disengaja.
Membantu menghindari kerentanan content-sniffing.
Dapat dikonfigurasi untuk menolak format berisiko seperti text/html di API.

Kesimpulan: Merangkul HTTP 406 Not Acceptable untuk Komunikasi yang Tepat

Kode status HTTP 406 Not Acceptable merepresentasikan prinsip penting arsitektur web: komunikasi yang jelas antara klien dan server tentang kemampuan dan persyaratan mereka. Ini bukan kesalahan yang harus ditakuti, tetapi mekanisme untuk memastikan bahwa pertukaran data terjadi dalam format yang saling dimengerti.

Meskipun Anda mungkin tidak menemukan 406 setiap hari, memahaminya membuat Anda menjadi warga web yang lebih baik. Ini mengajarkan pentingnya menjadi eksplisit tentang persyaratan format data dan menangani negosiasi format dengan anggun.

Untuk pengembang API, implementasi negosiasi konten dan respons 406 yang tepat mengarah pada API yang lebih kuat dan fleksibel. Untuk pengembang klien, memahami cara bekerja dengan kesalahan 406 memastikan aplikasi Anda dapat beradaptasi dengan kemampuan server yang berbeda.

Di dunia di mana data perlu mengalir di antara berbagai sistem dan platform, kemampuan untuk menegosiasikan format konten lebih berharga dari sebelumnya. Dan ketika Anda perlu menguji dan menyempurnakan negosiasi ini, alat seperti Apidog menyediakan lingkungan yang sempurna untuk memastikan aplikasi Anda berkomunikasi secara efektif, terlepas dari preferensi format.

button