Swagger adalah alat khusus yang secara otomatis menyusun dokumen RESTful API dari aplikasi Anda.
Keuntungannya terletak pada kenyataan bahwa itu memungkinkan Anda tidak hanya untuk melihat melalui semua titik akhir aplikasi, tetapi juga segera mengujinya dalam tindakan dengan mengirim permintaan dan menerima tanggapan.
Untuk mengakses Swagger , Anda perlu menekan tombol Preview di aplikasi yang diterbitkan dan klik nama rencana penerbitan yang diperlukan ( Deploy Plan ).
Di jendela yang baru dibuka, daftar titik akhir yang tersedia dan metode yang terkait dengan titik akhir ini akan ditampilkan. Beberapa permintaan hanya tersedia untuk grup pengguna resmi tertentu (lihat modul Middleware dari Auth module untuk setiap permintaan spesifik di bagian Endpoints ). Bearer Token diperlukan untuk permintaan yang diizinkan hanya untuk pengguna yang berwenang.
Anda dapat mengakses titik akhir yang sesuai secara langsung di Swagger untuk mendapatkan token ini (bagian Auth , POST /auth ).
Tekan Try it out dan masukkan login dan kata sandi untuk mendapatkan token.
Permintaan akan dikirim pada Execute . Jika berhasil, Anda akan melihat bidang token dengan nilai Bearer token .
Cara kedua untuk mendapatkan token pengguna yang diotorisasi adalah bahwa token tersebut dapat ditemukan di badan permintaan aplikasi yang digunakan.
- Tekan F12 di browser web Anda untuk membuka alat pengembang.
- Kirim permintaan apa pun di aplikasi yang Anda terapkan (untuk memperbarui tabel, misalnya). Pengguna yang mengirim permintaan ini harus diotorisasi untuk mengakses titik akhir ini.
- Buka tab Network dan temukan permintaan yang sesuai.
- Buka tab Headers dan temukan bagian Request Headers . Bearer token akan disajikan di bawah Authorization .
Berikan Bearer token ke Swagger dengan menekan Authorize dan tempel nilai yang Anda salin di langkah sebelumnya.
Untuk permintaan pengujian, pilih grup yang diinginkan dan metode yang ingin Anda jalankan. Tekan Try it out dan isi parameter input permintaan. Klik Execute untuk menjalankan respons.
Respons yang paling diharapkan, jika permintaan diproses dengan benar oleh server, memiliki kode 200 dan menunjukkan seperti apa struktur respons seharusnya.
401 - permintaan tidak berhasil diselesaikan karena token otorisasi yang diperlukan tidak ada atau tidak valid.
404 - permintaan berhasil diproses, tetapi sumber daya yang diminta tidak ditemukan.
422 - parameter yang salah diteruskan ke input permintaan.
500 - kesalahan saat memproses permintaan oleh server.
Naikkan Kesalahan Kustom
Untuk BP khusus dan permintaan terkait, dimungkinkan untuk membuat kode kesalahan khusus dengan deskripsi menggunakan blok Raise Error di editor BP. Contoh proses tersebut di bawah ini:
Dalam hal ini, jika permintaan ke titik akhir yang terkait dengan BP di atas gagal, server akan mengeluarkan kesalahan 418 yang berisi teks kesalahan saat menjalankan DB: Create Candidate block . Kode kesalahan dalam contoh ini dapat berupa salah satu yang ditentukan pengguna.
Catatan: HTTP 418 I'm a teapot client error response code menunjukkan bahwa server menolak untuk menyeduh kopi karena, secara permanen, adalah teko. Teko kopi/teh gabungan yang sementara kehabisan kopi seharusnya mengembalikan 503. Kesalahan ini mengacu pada Hyper Text Coffee Pot Control Protocol yang didefinisikan dalam lelucon April Mop pada tahun 1998 dan 2014.
