Best Practice untuk API Error | PZN Reaction

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...
KZbin : / programmerzamannow

[@alfuady]

{message, data} struktur terbaik sejauh ini sejak 2014 gua implement Rest API

[@kemaladityaz9833]

kadang males ngingetin krna takut di anggap nambah2in kerjaan, eh malah saya yg kbagian frontend yg keteteran 😫

[@Ariprw]

Bang Eko bahas backup data di production dong baiknya seperti apa 🙌🏻🔥🙌🏻

[@slingingslasher7427]

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.

[@yuu.relief]

HTTP Status 418 : I'm a teapot

[@egipebriyawan1455]

terhitung 3 kali divideo ini Pak Eko bilang "saya sih gak pernah ngasih status code" haha. bener2 keukeuh ceuk sunda mah . 😁

[@lyrihkaesa]

Agak susah sih kalau responnya acak" di saat harus consume api di type language, bikin banyak model respon yang perlu dibuat.

[@sayedkhaidirali7414]

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

[@speksuperhero]

Saya tau tuh yg dibahas sama bapak yg "error":"errors" 😂😂 Salah satu api yg sering bgt dipake di Indonesia 🤣🤣🤣

[@bisa_fullstack]

bener banget pak eko kalo response error nya gak informatif seperti itu, seakan akan kita menerawang sendiri dimana errornya bagai seorang spiritual😁

[@yasinhabib2029]

debug mode matiin, selalu gunakan try catch untuk meng-override exception

[@alvinxyz7419]

Status Code: 200 OK Body: { status: "error" } 😅

[@programmerviewid1768]

{status:200,message:"bad request",data:[]} 😂😂

[@muasx1985]

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.

[@muasx1985]

dan semoga sekarang sudah gak seperti tahun kemaren lagi

[@rafinurromadhon6905]

sangat bermanfaat mas eko bagi saya yang suka asal kasih message wkwk. terima kasih

[@Fuji-gn9nx]

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

[@startFromNull]

Paling bete ketika respon error tapi messagenya 200😊😅😅😅😅😅😮😮😢😢😢

[@reinjin2371]

jadi maksutnya sukses diproses tapi juga eror😂

[@slingingslasher7427]

@@reinjin2371 di hasil response nya error Tapi status yg dibuat dari back end 200 wkwkwk

[@simpingsyndrome]

Pass magang nih, APInya kek gini ngesellin, semuanya 200OK 🥴

[@user-es5bp3bw5z]

Pak review lok bit 32 dong

[@ptf42069]

yang penting itu important

[@tinkerbell2182]

Kang eko mau pembahasan bikin loging error yg pakai request_id itu ya atau ada source video contohnya ga ya . Nuhun kang 🙂

[@kamsurlabs]

konsisten, bersih dan informatif adalah koentji

[@ariflapengo3215]

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?

[@ProgrammerZamanNow]

harusnya temuin semua error dulu, di tiap teknologi udah ada validation framework, gak perlu satu2 lagi pake if else

[@ryu-xd]

22:53 bash script di dalam format extension file jpg atau png emang di eksekusi ? perasaan ga bisa

[@zulfikarsuwardi4015]

Pak Eko ada niatan untuk buat materi Laravel Zero ga ?

[@bangkuwarteg4719]

Pak ada rencana buat bikin course belajar python?

[@refanfernando6149]

tiap error dikirim "something bad happened" biar errornya bikin penasaran banyak orang 🤣🤣

[@ramdoni3935]

diri sendiri bilek : "sorry ya aku ini sebenernya programmer yang susah di tebak....

[@emitvi2347]

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

[@ProgrammerZamanNow]

Benar

[@insideofcode]

10:18 kurang fokus nih pak eko, bilangnya 200 karakter tapi yang muncul angaka 20 😄

[@ProgrammerZamanNow]

AI nya belum bisa nebak isi pikiran saya sepertinya

[@insideofcode]

@@ProgrammerZamanNow pak ada pembahasan multitenant architecture ga ?

[@belajarcoding6657]

Keren

[@minecrawlerarmor]

Pak Eko, ingin bertanya apakah bahasa low level seperti c/c++ worth di pelajari untuk loker indonesia

[@ProgrammerZamanNow]

masih dikit kalo di indonesia

[@YusnitaPanut-tg6ge]

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

[@ProgrammerZamanNow]

Waktu soft delete, jadiin null kolom unik nya

[@nurkholidf]

Pak eko masih sodaraan sama leon kennedy ?

[@user-iw5fe2hd3l]

klo status code disaya itu biasanya berupa "code" tertentu untuk translate message error spesifik kebutuhan bisnis... misal ERCA001 dkk gt lah bang

[@ProgrammerZamanNow]

cocok untuk mesin, gak cocok untuk manusia, orang bingung dengan error kode seperti ini

[@samuelhandoko5320]

@@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)

[@MuhamadIlham]

@@samuelhandoko5320yap gua juga nambahin itu biar ngetracenya mudah

[@juancesarAndrianto]

kalau ak tak bikin middleware global jadi response erorr dan response suksesnya itu sama semua

[@Fuji-gn9nx]

wa ini salah kayaknya bang, kalau gitu kan nanti erro database sama error akun sama pesan errornya, alhasil bingung

[@juancesarAndrianto]

@@Fuji-gn9nx kalau error db misal, code 500 langsung lempar aja errror nya yang penting struktur datanya sama baik error atau yang sukses.

[@Fuji-gn9nx]

@@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"

[@jeffryansyahputra3765]

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?

[@slingingslasher7427]

Ngirim datanya lewat fetch bang

[@Fuji-gn9nx]

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

[@youtube7959]

biasa bikin API pke apa nih ?

[@didirumapea6767]

pake joi/zod bagus ga pak eko ?

[@ProgrammerZamanNow]

bagus, di kelas saya pake itu

[@didirumapea6767]

@@ProgrammerZamanNow siap pakk.

[@jackwilliams4398]

kapankah kita butuh grpc?

[@slingingslasher7427]

Kalau make golang

[@Fuji-gn9nx]

​@@slingingslasher7427make semua bahasa bisa ga hanya golang