Best Practice untuk API Error | PZN Reaction
Вставка
- Опубліковано 19 сер 2024
- Best Practice untuk API Error | PZN Reaction
#programmerzamannow
JOIN PREMIUM : www.youtube.co...
DISCORD PREMIUM : • Post
Donasi :
Saweria : saweria.co/Pro...
Social Media :
Instagram : / programmerzamannow
Facebook : / programmerzamannow
Telegram : t.me/Programme...
UA-cam : / programmerzamannow
{message, data}
struktur terbaik sejauh ini sejak 2014 gua implement Rest API
kadang males ngingetin krna takut di anggap nambah2in kerjaan, eh malah saya yg kbagian frontend yg keteteran 😫
saya masih belajar
Untuk API saya biasa pakai struktur template seperti ini
id : string , ini sama seperti request_id nya pak eko biasanya formatnya username+ Unix time
took : number
data : T extends Object | null
error : K extends Object | null
message : string
Untuk yang error yang bagian errornya itu biasanya
count : number | null , kalau error 429
form : T extends Record | null , ini buat error kalau validasi form gagal yang T itu sesuai interface form nya.
untuk error yang sensitif misal errornya di class apa,SQL,line nya dimana di file apa itu gak dikirim ke response error, yang dikirim paling internal server error di message nya wkwk, informasi error seperti itu dikirimnya ke log
Kalau pesan errornya kan udah ada di bagian message,
Kalau status itu udah dikirim di back end nya, jadi yang diatas itu cuma isi response ya aja kurang lebih template nya seperti itu.
Btw yang mau koreksi atau ngasih saran reply saja komentar ini, kita sama-sama belajar.
Bang Eko bahas backup data di production dong baiknya seperti apa 🙌🏻🔥🙌🏻
Agak susah sih kalau responnya acak" di saat harus consume api di type language, bikin banyak model respon yang perlu dibuat.
HTTP Status 418 : I'm a teapot
saya biasanya kalo error stack itu cuma sampe log level aja, ga sampe response ke front-end, kecuali sedang dalam development, jadi biasanya kita bikin kondisi, untuk non-production env, kita balikin error stack nya kedepan, biar kalo misalnya error nya ga di tangkap di backend, frontend, dan juga QA mungkin detect error tersebut saat proses development
terhitung 3 kali divideo ini Pak Eko bilang "saya sih gak pernah ngasih status code" haha. bener2 keukeuh ceuk sunda mah . 😁
Saya tau tuh yg dibahas sama bapak yg "error":"errors" 😂😂
Salah satu api yg sering bgt dipake di Indonesia 🤣🤣🤣
debug mode matiin, selalu gunakan try catch untuk meng-override exception
Status Code: 200 OK
Body:
{
status: "error"
}
😅
nonton ini jadi ingat dulu pernah integrasi dengan "ekspedisi yang namanya sudah gede". detail error validationnya gak informatif banget hanya sekedar mengenai "field tidak sesuai dengan validasi". sudah begitu di dokumentasinya pun kurang jelas per field nya mengenai apa dan rules gimana. jadinya tiap ada error validasi mesti up ke group IT nya mengenai error tersebut.
dan semoga sekarang sudah gak seperti tahun kemaren lagi
bener banget pak eko kalo response error nya gak informatif seperti itu, seakan akan kita menerawang sendiri dimana errornya bagai seorang spiritual😁
{status:200,message:"bad request",data:[]} 😂😂
hal yang perlu diimprove saat ini adalah kemampuan debugging, pengendalian error, yang seperti itu, bukan lagi cara membuat. karena barusan aku kesel aplikasi mobile banking error ga jelas tulisannya "mohon install apk nya dari playstore" lah apk aku dari dulu dari playstore njir sebelumnya lancar tau-tau error kayak gitu njir :( seharusnya sebelum release update itu di test sampe bener-bener ga ada bug, ini ada bug direlease, sekelas apk bank lagi yang digunakan orang banyak dan penting karena untuk bayar belanja mereka, tadi ga bisa beli jadinya padahal promo murah
Kang eko mau pembahasan bikin loging error yg pakai request_id itu ya
atau ada source video contohnya ga ya . Nuhun kang 🙂
sangat bermanfaat mas eko bagi saya yang suka asal kasih message wkwk. terima kasih
Halo Bang Eko, izin stich ya
Saya rasa yg dimaksud di poin "Document common errors" (13:20) tuh agar yg bikin API menyertakan detil struktur pesan error, contoh dari pesan error-nya, dan saran buat mengatasi error-nya
Misal dengan contoh dari Bang Eko di 15:41, maka di dokumentasi API baiknya dijelasin apa maksudnya UNIQUE, TOO_LONG, dan MUST_BE_LETTERS. Terus bisa juga dikasi tau apa yang bisa menyebabkan API me-return kode2 tersebut
Benar
yang penting itu important
Paling bete ketika respon error tapi messagenya 200😊😅😅😅😅😅😮😮😢😢😢
jadi maksutnya sukses diproses tapi juga eror😂
@@reinjin2371 di hasil response nya error
Tapi status yg dibuat dari back end 200 wkwkwk
Pass magang nih, APInya kek gini ngesellin, semuanya 200OK 🥴
Pak review lok bit 32 dong
22:53 bash script di dalam format extension file jpg atau png emang di eksekusi ? perasaan ga bisa
Pak Eko ada niatan untuk buat materi Laravel Zero ga ?
Pak ada rencana buat bikin course belajar python?
Kang Eko, mau tanya
Kalau ada kolom di db itu unique, tapi pakai soft delete juga, baiknya bagaimana ngasih tau ke client yang consume API kita?
Kadang waktu cek di FE ga ada row itu, tapi waktu create gagal karena unique, waktu di cek di db ternyata ada tapi sudah di soft delete.
Best practice nya bagaimana itu Kang
Waktu soft delete, jadiin null kolom unik nya
mas mau tanya di menit 10:54 dijelaskan biasanya atau lebih baik errornya di detailkan gitu ya
tapi masalahnya klw kita nemuin suatu error kan langsung di break mas, misal di username kurang panjang nah ini langsung di break dan di return jadi keputus tuh pengecekan lainnya
apakah baiknya kita kalau nemuin error2 seperti ini baiknya di teruskan dulu pengecekannya agar mendapatkan validitas error message secara keseluruhan?
harusnya temuin semua error dulu, di tiap teknologi udah ada validation framework, gak perlu satu2 lagi pake if else
konsisten, bersih dan informatif adalah koentji
Pak Eko, ingin bertanya apakah bahasa low level seperti c/c++ worth di pelajari untuk loker indonesia
masih dikit kalo di indonesia
klo status code disaya itu biasanya berupa "code" tertentu untuk translate message error spesifik kebutuhan bisnis... misal ERCA001 dkk gt lah bang
cocok untuk mesin, gak cocok untuk manusia, orang bingung dengan error kode seperti ini
@@ProgrammerZamanNow keknya maksudnya gt deh.. nanti dari "kode" error itu di translate di fenya jadi bahasa manusia, jadi dari sisi user tahu errornya apa (even banyak kasus user tetep tanya errornya kenapa 😁), kita sebagai programmer juga bisa pinpoin buat checkingnya lebih cepet (kasus di saay programnya memang gede dan macem2,, klo di saya biar sat set carinya)
@@samuelhandoko5320yap gua juga nambahin itu biar ngetracenya mudah
tiap error dikirim "something bad happened" biar errornya bikin penasaran banyak orang 🤣🤣
diri sendiri bilek : "sorry ya aku ini sebenernya programmer yang susah di tebak....
Keren
10:18 kurang fokus nih pak eko, bilangnya 200 karakter tapi yang muncul angaka 20 😄
AI nya belum bisa nebak isi pikiran saya sepertinya
@@ProgrammerZamanNow pak ada pembahasan multitenant architecture ga ?
kalau ak tak bikin middleware global jadi response erorr dan response suksesnya itu sama semua
wa ini salah kayaknya bang, kalau gitu kan nanti erro database sama error akun sama pesan errornya, alhasil bingung
@@Fuji-gn9nx kalau error db misal, code 500 langsung lempar aja errror nya yang penting struktur datanya sama baik error atau yang sukses.
@@juancesarAndrianto itu buat user? yang buat developer gimana? kamu buat log ga? isi lognya kayak gimana? struktur datanya jelas sama kan sama-sama pakai database yang sama, ga dibedakan databasenya. bahkan kalau itu pesan error untuk user itu masih ga informatif kalau semua pesan error sama karena disetting lewat middleware, misal pesan error di middleware mu "error internal server" dengan kode 500, si user pas login salah memasukkan password dapat tulisan pesan error "error internal server", si usernya mikir gini tuh "waduh servernya error" alhasil dia akan nunggu servernya membaik bukan mengklik lupa password padahal errornya berkaitan dengan password, tetapi karena pesan errornya "error internal server" si user jadi ga ada pikiran buat klik lupa password, tapi malah nunggu server membaik padahal servernya udah baik, alhasil user ga pernah berhasil login karena dia tidak tau kalau yang error tuh passwordnya karena pesan errornya "error internal server"
biasa bikin API pke apa nih ?
izin nanya bang,
@21:20
kalo untuk edit data biasanya saya meletakkan id yang akan diedit pada hidden input (HTML+PHP), apakah cara ini tidak aman? bagaimana cara memvalidasi nya.. atau mengamankan nya?
Ngirim datanya lewat fetch bang
aman harusnya, metod request post, karena modal id aja ga bakal bisa ngehack kalau ga ter autentifikasi, makanya pastiin api nya hanya bisa diakses yang sudah terautentifikasi
Pak eko masih sodaraan sama leon kennedy ?
pake joi/zod bagus ga pak eko ?
bagus, di kelas saya pake itu
@@ProgrammerZamanNow siap pakk.
kapankah kita butuh grpc?
Kalau make golang
@@slingingslasher7427make semua bahasa bisa ga hanya golang