Ralat API Biasa dan Cara Membaikinya

Apabila membina mana-mana perisian sama ada laman web atau aplikasi, adalah satu kemestian untuk memasukkan jaminan kualiti ke dalam kitaran pembangunan perisian anda. Jika terlepas, terdapat kemungkinan besar untuk mengeluarkan contoh buggy yang pastinya akan merosakkan pengalaman pengguna akhir.

Tiada pihak berkepentingan yang mahu perkara ini berlaku. Itulah sebabnya ujian sentiasa berjaga-jaga untuk keluaran yang berjaya dan memastikan tindak balas yang positif terhadap ciri yang anda tambahkan. Ini memerlukan senario kes penggunaan yang paling biasa untuk mengesahkan bahawa aliran berfungsi seperti yang diharapkan sebelum mana-mana pelanggan sebenar anda berpeluang menyemaknya.

Apabila mempertimbangkan ujian yang perlu disertakan dalam suite liputan anda, beri perhatian kepada ujian API, kerana ia merupakan salah satu jenis yang paling penting dan digunakan secara meluas. API ( Antara Muka Pengaturcaraan Aplikasi) terdapat dalam mana-mana aplikasi dan bertanggungjawab untuk komunikasi yang betul antara beberapa sistem perisian. Fungsi utama API termasuk menentukan permintaan data yang boleh dihantar dan syarat untuk permintaan ini diproses. 

Sebagai contoh, pengguna ingin menambah beberapa item pada troli, menekan butang sepadan yang mencetuskan permintaan API, menerima respons dan troli dikemas kini. Jika permintaan ini gagal, ciri "tambah ke troli" akan rosak.

Begitulah cara isu dengan API boleh menjejaskan perniagaan, menambah satu lagi faktor penting mengapa semua orang harus mengujinya dengan betul. Untuk menggabungkan ujian ini, seseorang harus bermula dengan alat ujian API automasi yang betul untuk memastikan tiada ralat tergelincir.

Mungkin terdapat ralat API yang berbeza, dan di sini kami akan memberitahu anda lebih lanjut tentang 5 yang paling popular: 

Kaedah HTTP yang salah

Ralat API yang paling mudah tetapi tersebar luas ialah kaedah HTTP yang salah. Selalunya, isu ini disebabkan oleh jurang dalam dokumentasi. Salah satu contoh mungkin menghantar permintaan GET yang menyatakan pilihan data, tetapi langkau menyebut parameter -X GET. Akibatnya, ia akan ditukar secara automatik kepada permintaan POST. Selain itu, isu dengan kaedah HTTP mungkin berlaku apabila menukar alatan API kerana sesetengah daripada mereka mungkin menggunakan satu kaedah untuk mencipta persekitaran ujian dan mengubah suainya, manakala yang lain menggunakan cara yang berasingan untuk tindakan ini. Itulah sebabnya penting untuk menyemak nuansa ini dengan teliti, serta menggunakan pendekatan yang konsisten untuk menulis dokumentasi anda sendiri. 

Menggunakan protokol yang salah

Satu lagi ralat biasa ialah percanggahan antara protokol https:// dan http://. Sesetengah API mungkin menyokong hanya satu daripada protokol, katakan http, jadi menyatakan https:// dalam kes sedemikian akan membawa kepada pemprosesan permintaan yang salah. Walaupun kedua-duanya disokong, mungkin terdapat masalah dengan ubah hala ke https:// apabila anda menentukan http://. Kes ini juga mungkin berlaku apabila penyedia API pihak ketiga yang anda rancang untuk gunakan membuat beberapa perubahan dan gagal menghantar pemberitahuan tentang itu. Jadi adalah lebih baik untuk menyemak semula aspek ini dari semasa ke semasa. Untuk mencipta API anda sendiri, lebih baik menggunakan protokol https://. Untuk membolehkannya, anda perlu memasang sijil SSLkepada tuan rumah. Beberapa ketika dahulu, sijil SSL agak mahal jadi mungkin ada keraguan mengenainya, tetapi dengan pembekal percuma seperti Letsencrypt atau Cloudflare, ia menjadi lebih mudah berbanding sebelum ini.

Ketiadaan mesej ralat yang bermakna

Jika anda pernah menghadapi " ralat API yang tidak dijangka”, anda tahu betapa menjengkelkannya yang ini. Biasanya, mesej ralat sepatutnya memudahkan penyelesaian masalah untuk pembangun menunjukkan sebab sebenar ralat atau sekurang-kurangnya di mana untuk mencarinya. Malangnya, ralat tidak bermaklumat tersebut boleh mengakibatkan jam masa terbuang, meningkatkan masa yang diperlukan untuk menyelesaikan ralat dan seterusnya menyebabkan lonjakan yang lebih besar dalam maklum balas negatif yang anda terima, itulah sebabnya adalah lebih baik untuk meluangkan sedikit lebih masa untuk menerangkan potensi kesilapan dan menjadikan mesej bermaklumat untuk mereka yang perlu menyelesaikan masalahnya. Walaupun terdapat beberapa dozen kod ralat HTTP, anda tidak perlu menggunakan kesemuanya, tetapi simpan kod ralat standard (200,400 dan 500) dan pertimbangkan untuk memasukkan pembayang ke dalam mesej supaya walaupun dalam kes apabila sesuatu tidak berfungsi,

Masalah kebenaran

Nampaknya di sini semuanya jelas kerana kebenaran yang salah biasanya mengandaikan bahawa nama pengguna atau kata laluan adalah salah, tetapi sebenarnya, walaupun mengelirukan "keizinan" dengan "pengesahan" dalam pengepala menyebabkan ralat. Ia sangat sah dalam menggunakan protokol OAuth 2. Juga, sintaks penting, kerana beberapa perkara yang mudah tetapi kurang jelas boleh menimbulkan kekeliruan. Dalam kebanyakan kes, ini ialah token pembawa, ruang dalam awalan "Asas", tiada untuk menambah awalan ini sepenuhnya dan kehilangan titik bertindih dalam pasangan "nama pengguna: kata laluan". Walaupun nama pengguna digunakan secara bersendirian dalam sesetengah API yang tidak memerlukan kata laluan, anda masih perlu menggunakan titik bertindih ini.

Gagal menentukan pengepala Jenis Kandungan dan Terima

Sesetengah API bertolak ansur dengan permintaan apabila pengepala tidak mengandungi Pengepala Jenis Kandungan atau Terima tetapi sepadan dengan format data yang dibenarkan. Yang lain lebih teliti dan tidak akan membenarkan permintaan melalui pemberian kod ralat 403 Permission Denied. Pada peringkat ini, interaksi antara klien dan pelayan mengenai jenis data yang dijangkakan dalam permintaan dan respons diwujudkan. Semakan pengepala ini dilaksanakan untuk mengurangkan risiko pelanggaran keselamatan dan percubaan penggodaman keseluruhan, itulah sebabnya adalah lebih baik untuk menentukan pengepala ini untuk mengelakkan sebarang masalah semasa penggunaan.

Bungkus

Melakukan ujian API bersama-sama dengan jenis ujian lain termasuk regresi, ujian asap dan sudah tentu, ujian unit semasa pecut pembangunan akan membantu keluaran perisian anda berlaku dengan lebih pantas. Logik di sebaliknya adalah mudah: lebih cepat pepijat, kecacatan atau ketidakkonsistenan dengan keperluan perniagaan diperhatikan, lebih mudah untuk membetulkannya. Dan, sebagai hasilnya, berikan pengalaman terbaik kepada pengguna akhir anda yang akan dapat menikmati interaksi dengan perisian anda tanpa pepijat yang tidak dijangka dalam proses itu, sekali gus membawa lebih banyak keuntungan kepada perniagaan anda.