REST gairah untuk 200

Saya sudah lama ingin menulis artikel ini. Saya terus bertanya-tanya sisi mana yang lebih tepat untuk masuk. Tapi, tiba-tiba, baru-baru ini, sebuah artikel serupa muncul di Habré, yang menyebabkan badai di gelas. Yang paling mengejutkan saya adalah fakta bahwa artikel itu mulai didorong dalam minus, meskipun bahkan tidak menyatakan sesuatu, tetapi lebih menimbulkan pertanyaan tentang menggunakan kode respons server web di REST. Perdebatan berkobar panas. Dan pendewaannya adalah bahwa artikel tersebut masuk ke konsep ... kilobyte komentar, pendapat, dll. menghilang begitu saja. Banyak yang menjadi korban karmo, pertimbangkan, tanpa hasil :)

Secara umum, nasib artikel itulah yang mendorong saya untuk menulis yang ini. Dan saya sangat berharap ini akan bermanfaat dan banyak menjelaskan.

Saya memperingatkan Anda, semua yang ditulis di bawah ini adalah pengalaman nyata, bukan tindakan penyeimbangan kognitif. Jadi, mereka menyetir.

HTTP

Hal pertama yang harus dilakukan adalah memisahkan layer-layer dengan sangat jelas. Lapisan transport adalah http. Ya, sebenarnya ISTIRAHAT. Ini adalah hal yang secara fundamental penting dalam menerima segala sesuatu dan “diri Anda” di dalamnya. Mari kita bicara tentang http dulu saja.

Saya menggunakan istilah "layer transport". Dan saya tidak melakukan reservasi. Masalahnya adalah bahwa http itu sendiri mengimplementasikan fungsi pengangkutan permintaan ke server dan konten ke klien, terlepas dari tcp / ip. Ya, ini didasarkan pada tcp / ip. Dan tampaknya, perlu untuk menganggapnya sebagai transportasi. Tapi tidak. Dan inilah sebabnya - koneksi soket tidak langsung, mis. ini bukan koneksi client-server. Baik permintaan http maupun respons http dapat memberikan banyak manfaat. Mereka dapat dikumpulkan atau diuraikan sebaliknya. Dapat di-cache, dapat dimodifikasi.

Yaitu baik permintaan http maupun respons http memiliki rute sendiri. Dan itu tidak bergantung pada ujung belakang, juga pada ujung depan. Saya meminta Anda untuk memberikan perhatian khusus pada ini.

Rute http tidak statis. Mereka bisa sangat rumit. Misalnya, jika penyeimbang dibangun ke dalam infrastruktur, ia dapat mengirim permintaan yang diterima ke salah satu back-node. Pada saat yang sama, backend itu sendiri dapat mengimplementasikan strateginya sendiri untuk bekerja dengan permintaan. Beberapa dari mereka akan pergi ke microservices secara langsung, beberapa akan diproses oleh server web itu sendiri, beberapa akan ditambahkan dan ditransfer ke orang lain, dan beberapa akan dikeluarkan dari cache, dll. Beginilah cara kerja Internet. Tidak ada yang baru.

Dan di sini penting untuk dipahami - mengapa kita membutuhkan kode respons? Masalahnya adalah bahwa seluruh model yang dijelaskan di atas membuat keputusan berdasarkan pada mereka. Yaitu ini adalah kode yang memungkinkan Anda untuk membuat keputusan infrastruktur dan transportasi selama http routing.

Misalnya, jika penyeimbang menemukan kode respons dari mendukung 503, saat mengirim permintaan, ia dapat menganggap ini sebagai dasar untuk mempertimbangkan bahwa simpul tersebut sementara tidak tersedia. Saya perhatikan bahwa respons dengan kode 503 menyediakan tajuk Coba Lagi. Setelah menerima dari header interval untuk pemungutan suara berulang, penyeimbang akan meninggalkan node sendirian untuk periode yang ditentukan dan akan bekerja dengan yang tersedia. Selain itu, strategi tersebut diimplementasikan "out of the box" oleh server web.

Offtopic kecil untuk kedalaman pemahaman - bagaimana jika node merespons 500? Apa yang harus dilakukan penyeimbang? Beralih ke yang lain? Dan banyak yang akan menjawab - tentu saja, semua alasan 5xx untuk menonaktifkan simpul. Dan mereka akan salah. Kode 500 adalah kode kesalahan yang tidak terduga. Yaitu yang mungkin tidak akan pernah terjadi lagi. Dan yang paling penting, beralih ke node lain mungkin tidak mengubah apa pun. Yaitu kami cukup menonaktifkan node tanpa manfaat sedikit pun.

Dalam kasus 500, statistik datang membantu kami. WEB-server lokal dari node dapat menerjemahkan node itu sendiri ke status tidak tersedianya dengan sejumlah besar jawaban 500. Dalam hal ini, penyeimbang yang menghubungi node ini akan menerima respons 503 dan tidak akan menyentuhnya. Hasilnya sama, tetapi sekarang, solusi ini bermakna dan menghilangkan respons "salah".

Tapi itu belum semuanya. Dalam situasi ini, pemantauan akan memungkinkan admin untuk terhubung ke situasi untuk mempertahankan node. Yaitu kami mendapatkan tidak hanya penerapan layanan yang sangat mudah diakses, dengan penyeimbang, dll, tetapi juga proses dukungan yang efektif.

Dan semua ini memungkinkan Anda membuat kode respons server. Setiap arsitektur aplikasi WEB harus dimulai dengan desain layer transport. Saya harap tidak ada keraguan tentang itu.

SISA

Saya akan mengajukan pertanyaan retoris - apa itu? Dan apa yang Anda jawab padanya? Saya tidak akan memberikan tautan ke bukti yang jelas, tetapi kemungkinan besar itu tidak sesuai dengan kenyataannya :) Ini hanya sebuah ideologi, gaya. Beberapa pertimbangan pada topik - cara terbaik untuk berkomunikasi dengan belakang. Dan tidak hanya berkomunikasi, tetapi berkomunikasi dalam infrastruktur WEB. Yaitu berdasarkan http. Dengan semua "hal berguna" yang saya tulis di atas. Keputusan utama untuk mengimplementasikan antarmuka Anda selalu menjadi milik Anda .

Pernahkah Anda bertanya-tanya mengapa transportasi terpisah untuk REST tidak ditemukan? Misalnya, untuk websocket itu. Ya, itu juga dimulai dengan http, tetapi kemudian, setelah koneksi dibuat, ini umumnya lagu yang terpisah. Mengapa tidak melakukan hal yang sama untuk REST?

Jawabannya sederhana - mengapa? Ada protokol yang indah, siap pakai, dan diverifikasi - http. Ini bersisik dengan baik. Memungkinkan Anda menerapkan layanan yang rumit dan mudah diakses yang dapat mengatasi beban berat. Yang diperlukan hanyalah memperkenalkan beberapa aturan konseptual agar pengembang saling memahami.

Dari sini mengikuti kesimpulan sederhana dan jelas - segala sesuatu yang melekat pada http melekat pada REST. Ini adalah entitas yang tidak terpisahkan. Tidak ada header REST terpisah, bahkan tidak ada petunjuk bahwa REST adalah REST. Untuk setiap server REST, permintaannya persis sama dengan yang lain. Yaitu REST adalah apa yang ada dalam pikiran kita.

SISA kode respons http

Mari kita bicara tentang kode apa server Anda harus menanggapi permintaan REST? Secara pribadi, menurut saya bahwa dari semua hal di atas, jawabannya sudah jelas, karena REST tidak berbeda dari permintaan lain, itu harus tunduk pada aturan yang persis sama. Kode respons adalah bagian integral dari REST dan harus relevan dengan esensi respons. Yaitu jika objek tidak ditemukan berdasarkan permintaan, itu adalah 404, jika klien membuat 400 permintaan yang salah, dll. Tapi, paling sering, perdebatan tidak berakhir di situ. Karena itu, saya akan melanjutkan.

Apakah mungkin untuk menjawab semuanya dengan kode 200? Dan siapa yang akan melarangmu? Tolong ... kode 200 adalah kode yang sama dengan yang lain. Benar, dasar dari pendekatan ini adalah tesis yang sangat sederhana - sistem saya sempurna, tidak ada kesalahan. Jika Anda adalah orang yang dapat membuat sistem seperti itu - ini hanya dapat membuat iri!

Tapi kemungkinan besar ... dia tidak sempurna. Dan kesalahan bisa terjadi. Dan itu terjadi karena keadaan di luar kendali kami. Dan di sini solusi tipikal adalah membuat sistem pengkodean kesalahan Anda sendiri. Apakah itu buruk? Ya itu buruk. Ini sangat buruk. Mari kita cari tahu alasannya.

Maka, dengan mengambil kode 200 sebagai satu-satunya yang benar, kami bertanggung jawab untuk mengembangkan seluruh lapisan (lapisan kritis) sistem - penanganan kesalahan. Yaitu kerja banyak orang untuk mengembangkan lapisan ini dikirim ke memo. Dan pembangunan "sepedanya" dimulai. Tapi mega-bangunan ini ditakdirkan untuk gagal.

Mari kita mulai dengan kodenya. Jika kita akan menjawab semua 200, kita sendiri harus menangani kesalahan. Metode klasik adalah mencoba membangun. Setiap segmen kode kami bungkus dengan kode tambahan. Penangan yang melakukan sesuatu yang bermanfaat. Misalnya, mereka memasukkan sesuatu ke dalam log. Sesuatu yang penting. Itu akan melokalisasi kesalahan. Dan jika kesalahan muncul bukan di tempat yang diharapkan? Atau jika kesalahan terjadi pada penangan kesalahan? Yaitu strategi ini pada level kode tidak berfungsi apriori. Dan pada akhirnya, interpreter atau platform akan memproses bug Anda. OS akhirnya. Inti dari bug adalah Anda tidak menunggu untuk itu. Anda tidak perlu menyembunyikannya, Anda harus mencari dan memperbaikinya. Oleh karena itu, jika REST menanggapi beberapa permintaan dengan kesalahan 500, ini normal . Dan apa lagi, benar .

Mari kita kembali ke pertanyaan - mengapa ini benar? Karena:

1. Kode 500 adalah token infrastruktur yang didasarkan pada simpul di mana masalah terjadi dapat dinonaktifkan;
2. Kode 5xx adalah apa yang sedang dipantau dan jika kode tersebut muncul, sistem pemantauan apa pun akan segera memberi tahu Anda mengenai hal ini. Dan layanan dukungan pada waktunya akan dapat terhubung ke solusi masalah;
3. Anda tidak menulis kode tambahan. Jangan buang waktu yang berharga untuk ini. Jangan menyulitkan arsitektur. Anda tidak berurusan dengan masalah yang tidak biasa bagi Anda - Anda menulis kode aplikasi. Apa yang mereka inginkan dari Anda. Apa yang mereka bayar?
4. Jejak yang jatuh karena kesalahan 500 akan jauh lebih berguna daripada upaya Anda untuk melampaui itu.
5. Jika permintaan REST mengembalikan 500 kode, bagian depan sudah pada saat memproses respons akan tahu oleh algoritma apa untuk memprosesnya. Selain itu, esensi dari masalah ini tidak akan berubah dengan cara apa pun, Anda belum menerima apa pun yang masuk akal baik dari 200 dan dari 500. Tetapi dari 500 Anda telah menerima keuntungan - kesadaran bahwa ini adalah kesalahan yang TIDAK DIKENALKAN.
6. Kode 500 akan datang dengan jaminan. Tidak peduli seberapa buruk atau baiknya Anda menulis kode Anda. Ini adalah titik tumpu Anda.

Secara terpisah, saya akan memalu paku ke seluruh "tubuh" kode 200:

7. Bahkan jika Anda berusaha sangat keras untuk menghindari kode respons lain dari server selain dari 200 permintaan Anda, Anda tidak dapat melakukan ini. Server perantara mana pun dapat menanggapi permintaan Anda dengan benar-benar kode apa pun. Dan Anda HARUS memproses jawaban seperti itu dengan benar.

Total, pada level logis, perjuangan untuk kode 200 tidak ada artinya.

Sekarang mari kita kembali ke level infrastruktur. Sangat sering saya mendengar pendapat - kode 5xx bukan tingkat aplikasi, tidak dapat diberikan dukungan. Ahem, well ... ada kontradiksi dalam pernyataan itu sendiri. Anda bisa memberi. Tetapi kode ini bukan level aplikasi. Itu lebih benar. Untuk memahami ini, saya mengusulkan untuk mempertimbangkan kasus ini:

Anda menerapkan gateway. Anda memiliki beberapa DC, masing-masing dengan saluran komunikasinya sendiri ke layanan pribadi tertentu. Nah, misalnya, membayar melalui VPN. Dan ada saluran komunikasi dengan Internet. Anda menerima permintaan untuk operasi dengan gateway, tetapi ... layanan tidak tersedia.

Jadi apa yang harus Anda jawab? Kepada siapa? Ini adalah masalah infrastruktur, dan, khususnya, back-up menabraknya. Tentu saja, Anda perlu menjawab dengan berani 503. Tindakan ini akan mengarah pada fakta bahwa simpul akan dinonaktifkan oleh penyeimbang untuk beberapa waktu. Pada saat yang sama, penyeimbang, jika dikonfigurasi dengan benar, tanpa memutus koneksi dengan klien, akan mengirim permintaan ke node lain. Dan ... pelanggan akhir, dengan tingkat probabilitas tinggi, menerima 200. Dan bukan deskripsi khusus tentang kesalahan, yang tidak akan membantunya dengan cara apa pun.

Di mana dan kode apa yang digunakan

Pertanyaannya tidak sederhana. Tidak ada jawaban pasti untuk itu. Untuk setiap sistem, lapisan transport dirancang dan kode di dalamnya mungkin spesifik.

Ada standar yang diterima. Mereka dapat dengan mudah ditemukan dan, sekali lagi, saya tidak akan memberikan bukti yang jelas. Tapi, saya akan memberi Anda hal yang tidak jelas - developer.mozilla.org/en/docs/Web/HTTP/Status
Mengapa dia Masalahnya adalah bahwa penangan kode dapat berperilaku berbeda, tergantung pada implementasi dan konteks "memahami kode." Misalnya, browser memiliki strategi caching berdasarkan kode respons. Dan beberapa layanan memiliki kode kustom sendiri. Misalnya, CloudFlare.

Yaitu membuat keputusan tentang penggunaan kode, Anda harus mendasarkan pada semua elemen yang termasuk dalam lapisan transport dari kode Anda di bagian belakang ke kode pada klien. Ini adalah satu-satunya cara untuk menemukan jawaban yang benar. Saya bahkan tidak akan mencoba memberi semua orang pil universal di sini.

Akar kejahatan

Ini adalah proyek ketiga yang saya dapatkan dari kode 200 di REST. Itu adalah penderitaan. Tidak ada kata lain. Jika Anda dengan cermat membaca semuanya hingga saat ini, Anda sudah memahami bahwa begitu proyek mulai tumbuh, ia membutuhkan pengembangan infrastruktur, untuk keberlanjutannya. Kode 200 membunuh semua upaya ini sejak awal. Dan hal pertama yang harus Anda lakukan adalah menghancurkan stereotip.

Akar kejahatan, menurut saya, terletak pada kenyataan bahwa kode 500 adalah hal pertama yang dihadapi seorang pengembang web dalam karier profesionalnya. Bisa dikatakan cedera masa kecil. Dan semua usahanya pada awalnya direbus untuk mendapatkan kode 200.

Ngomong-ngomong, untuk beberapa alasan, pada tahap yang sama, sebuah pendapat yang kuat berkembang bahwa hanya jawaban dengan kode 200 yang dapat diberikan bersama sebuah badan. Tentu saja, ini tidak benar, dan jawaban apa pun dapat “datang” dengan kode apa pun. Kode adalah kode. Tubuh adalah tubuh.

Selanjutnya, dengan pengembangan pengembang, ia perlu mengelola bug dari aplikasinya sendiri. Tapi ..., dia tidak tahu cara menggunakan log. Tidak dapat mengonfigurasi server web. Dia sedang belajar. Dan mereka yang "luar biasa" lahir. Karena mereka tersedia baginya dan dia dapat dengan cepat membuatnya. Selanjutnya, pada "hebat" ini dia memasang roda baru, memperkuat bingkai, dll. Dan yang hebat ini menjadi temannya untuk jangka waktu yang cukup lama, sampai ... sampai dia memiliki tugas multikomponen yang benar-benar kompleks. Dan di sini, seperti yang mereka katakan - pintu masuk ke supermarket dengan sepatu roda "hebat" dan skating dilarang.

PS: Penulis artikel yang disebutkan mengembalikannya dari draft - habr.com/en/post/440382 , sehingga Anda dapat membiasakan diri dengannya juga.

PPS: Saya mencoba menyatakan semua segi kebutuhan untuk menggunakan kode respons yang relevan di REST. Saya tidak akan menanggapi komentar, tolong mengerti saya dengan benar. Saya akan membacanya dengan penuh perhatian, tetapi tidak ada yang perlu saya tambahkan. Terima kasih banyak karena cukup sabar untuk membaca artikel ini!