Best Practice untuk Response API
Vložit
- čas přidán 23. 08. 2024
- Best Practice untuk Response API
#programmerzamannow #api #bestpractice
JOIN PREMIUM : www.youtube.co...
DISCORD PREMIUM : • Post
Donasi :
Saweria : saweria.co/Pro...
Social Media :
Instagram : / programmerzamannow
Facebook : / programmerzamannow
Telegram : t.me/Programme...
CZcams : / programmerzamannow
Terimakasih pak Eko atas ilmunya, dulu sering gini kalo bikin response API sampai² sering kena tegur dari mobile dev karena responnya tidak konsisten, lalu ada temen yg menyarankan bisa pakai standarnya JSON:API spec ini ngebantu banget untuk proses development udah banyak SDKnya untuk server dan client
emang kalo udah pake standarisasi, gak bisa komplen lagi, hehe
Ini yang ditunggu2! Pembahasan tentang tips dan best practice. Semoga kedepan banyak konten2 kya gini. 🤩👍
Semoga bermanfaat 😊
Dulu pernah iseng nanya sama developer yang selalu balikin status code 200 walaupun error. Jadi mereka ngasih 200 itu karna patokannya “berhasil hit API tsb”, jadi kalo gagal dari busineess logic tetep balikin 200, karena client dianggap berhasil akses si API. Kalo ada error di logic, tinggal tambahin error=false sama message nya apa. Dari penjelasan mas eko, emang lebih bagus balikin sesuai standard http aja. Biar gampang monitoring error di third party (kaya google cloud logging)
nah sbg devops sy setuju yg ini karena beberapa server akan terganggu health checknya karena memonitor 4xx dan 5xx. sebaiknya respon http digunakan untuk respon protocol bukan apinya. jadi kita bisa membedakan mana masalah di infra mana yg bukan. tapi terseah developernya sie, apa daya sebagai babu developer harus nurut.
@@guniwera kalo saya kurang setuju sih untuk penggunaan 200 tapi “patokannya dari berhasil hit ke server”, karena akan ganggu di monitoring lognya. saya pakai gcloud logging, di dashboard itu ada minitor berdasarkan http status code. jadi lebih mudah untuk nge trace error jika ada fitur yang baru up ke prod
Mantap pak eko, sangat membantu sekali dalam penerapan di project² freelance saya yang sederhana, selanjutnya bisa minta tolong bahas API security pak eko 🙏🏻
Mantap sukses selalu 🔥
Onpause 3:11: Kalo saya 3xx ini berguna di api jika terjadi session end, kenapa saya menerapkan itu? karena saya pernah dapet kasus (sederhana sebenernya) pengguna ini perangkatnya tidak pernah melakukan shutdown, melainkan disleep, dalam hal ini pengguna menggunakan laptop. Misalkan hari ini pengguna sudah mensubmit beberapa data yang fokus pada form ABC, lalu karena sudah mau pulang, ia langsung sleep laptopnya tanpa menutup browsernya, jadi masih ada tab form ABC. Keesokan harinya pengguna ini buka laptop untuk lanjutkan tugas yang sama pada form ABC, tapi ia tidak refresh dulu pagenya, nah ketika proses submit maka muncul error, report lah ke saya. Pas saya cek itu sepele sekali, jadi karena pada controller membutuhkan data Auth::user() (dalam hal ini saya pakai Laravel) yang mana butuh login untuk get datanya, sehingga terjadi error catch 500 yang dibalikkan dari proses DB::commit(). Nah dari sini saya gunakan 3xx ini pada route api, sehingga jika pengguna terkena session end pada saat form submit yang membutuhkan Auth::user() maka saya balikkan 3xx sebelum memproses DB:commit(). Jadi nanti response conditionnya minta window untuk reload page dan otomatis redirect to login page.
Kenapa ngga 401 atau 403 aja bang? Ntar redirectnya yg ngatur FEnya
@@kudriabdulnaim7660 403 Forbidden untuk role user privilege access / forbidden, 401 Unauthorized untuk kondisi apakah api endpointnya dapat diakses tanpa login atau tidak. Kembali lagi ke kebiasaan aja ini mah, selama konteksnya sesuai
kalau boleh tau mas, ini cara buatnya gmn ya... Kebeneran lagi belajar bikin API pake Laravel + Sanctum kalau di postman authorization bearer tokennya salah kena error 500 bukannya 401
ada referensi ga atau bisa di ketik disini detailnya
sorry bgt soalnya udah nyari ga ketemu, bingung keyword bahasa inggris nya di google
atur nuhun
moga jadi ladang jariyah mas Eko untuk ilmu ilmu yg bermanfaatnya
Saya pribadi lebih suka mengikuti JSON-RPC 2 menggunakan "result" daripada "data" karena hasil fetch api kan sdh ada di dalam "data", di frontend jadinya awkward mengakses response.data.data
"code" dan "status" jga gak perlu lgi karena redundat, udh ada di dalam response.status dan response.statusText. hehe
Kalo ada QA backend nya pasti disemprot sih ini kalo ga ada standar status code response wkwk
Tapi nyatanya di lapangan banyak juga yg polanya status code 200, ngandelin dari validasi response body aja.
Bahkan ada beberapa perusahaan luar, ketika saya integrasikan. Polanya sama status code 200, dan ngandelin responseCode di body, misal responseCode=SUCCESS/NOT FOUND/dll.
Memang yang pola status code 200, lebih mudah dipakai. Cukup onSuccess, dan baca responseCode di body.
Sedangkan yang status code tidak selalu 200, salah satu samplenya di angular, httpClientnya untuk status selain 200 masuk ke error, harus di handle onError, baru cek bodynya lagi. Memang nambahin beberapa flow lagi.
ya itu yang harusnya masuk ke konditional error secara otomatis, disitu kita malah bikin konditional error nya ketika success.. kan jadi gk bagus kualitas kodingannya..
Alhamdulillah kang dapet pencerahan, saya sering nampilin eror itu cuman message: tidak ditemukan.
Sehat terus kang 🙏
Semoga bermanfaat
Ada beberapa api yg saya tau, selama otorisasi beres & endpoint bener, semua responnya http 200, tapi di bodynya ada status code, 0 untuk sukses & kode lain kalau error atau ada request yg kurang
Kalau resultnya tidak ada, tetep respon http 200, status code 0, & array data = [ ]
Ga tau tp kyk udah standar umum dan kita sbg client jd nyaman, kalo 404 jangan2 endpoint yg salah
biasanya itu yang bikinnya kebawa2 gaya SOAP Web Service, pas pindah ke RESTful, dibawa gaya nya
@@ProgrammerZamanNow woaaah gitu ya bang... Wawasan baru nih (SOAP) buat ane yg pemula... Makasih bang sukses selalu
terima kasih atas video yang bagus ini.
Semoga channelnya makin berkembang.
semoga kreator video terus semangat membuat video baru dan bagi yang sengaja atau tidak sengaja baca komen ini
semoga sukses terus ya.
Makasih dukungannya
Setuju banget sama Mas Eko. buat saya yang dari sisi frontend pake react, status http response yang di kasih penting banget. karena kita biasa pake try catch.. ketika response http nya error tapi dia malah kasih status 200, jadi gk masuk ke konditional catch nya, jadi malah harus bikin conditional di bagian try nya yang bikin kualitas kodingannya jadi kurang bagus..
Bener tuh, dibagian try nya jadi harus ngebaca response data nya. Biasa res.data nya kalo misal error ngebalikinnya error. Tapi statusnya tetep 200, ini secara code jadi jelek di frontend, padahal ekspektasi nya ketika error dia masuk ke catch nya
bener gan, backend di gw gitu return 200 mulu, gw gimana negur nya ya ke backend wkwkw
@@wawanneutron omongin baik", kalo masih gitu juga pukul aja kepalanya wkowkwokwo. Canda pala
@@zul.overflow ahaha sabar Mas
Wah trnyata yg sya lakuin dgn tim hampir mirip sama yg pak Eko sampaikan yg bagian response data dan pagination, pdhal itu structure yg tdk planing (tdk sengaja) terima kasih sharing nya pak, masih follow utk ilmu2 lainnya
Waktu itu karena masing baru di per apian, cara saya contek response api di blibli dan sampai sekarang saya pakai acuan itu.
mantap
Daging banget materinya. makaasih pak eko sharingnya, fix auto benerin di project sendiri karna selama ini masih asal bikin response API wkwk
semoga bermanfaat
Sip mas 👍
nanti aku coba kirim ini video ke senior BE saya, soalnya kalau saya yang ngasih tau ngeyelan bener mentang - mentang saya minim pengalaman seenaknya.
4xx itu terkait kesalahan user.
5xx itu umumnya terkait exception
2xx itu menunjukkan bahwa permintaan diproses oleh server dengan baik tanpa ada exception. Klo empty result bisa kasih 204. Kalau dikasih 404 maka akan membingungkan apakah alamat url yg tidak ditemukan? Atau alamat API yg tdk ditemukan atau apa yg tidak ditemukan.
Analoginya semisal alamat web ketika membuka alamat dr page yg tdk ada kasih 404,tapi jika page nya ada misal halaman produk, maka halamannya tetap tampil meskipun tidak ada datanya. API pun demikian.
Jadi utk empty result sebaiknya menggunakan 200 atau 204 No Content. Ini menunjukkan bahwa request diterima dan diproses dgn baik oleh server namun data tidak ada.
Bayangkan misal kita sebagai web client mau menampilkan inbox pesan teks pd hari ini. Nah ketika empty result namun respon nya adalah 404 maka kita web client akan redirect ke halaman 404 not found. Padahal harusnya tetap menampilkan halaman inbox dgn tambahan info bahwa tidak ada pesan baru... Jika 404 maka client bingung,dikira url atau endpoint nya tidak ada...
Saya setuju dengan ini, kita tidak bisa memberikan response 404 untuk barang yang tidak ditemukan.
Karena, kalau ngeyel tetap httpstatuscode 404, gimana membedakan endpoint not found dan item not found.
Pas pertama kali belajar bikin API, hal yang saya bingungin yaitu bikin response-nya. Jadinya nyari-nyari referensi untuk best practice-nya dan lihat-lihat dari API yang udah jadi, terus diikuti response-nya. BTW makasih pak eko.
Dengan segudang pengalaman pak eko, kalau bisa berbagi ttg best practice, standarisasi, atau tips2 pemrograman pak. Pasti sangat bermanfaat dan membantu programmer lain utk naik kelas 😁
best moment ketika dikatakan ngeyel, atau kekeuh orang nya di komentari ngga mau / ngga terima, saya pernah ngasih training buat anak background IT freshgraduate masalah response, saya expert di FE memang bisa di handle dengan status code 200, tapi itu ribet banget buat tracking error nya, padahal simple tinggal kasih try catch pake webservice nya atau BE, tapi ya balik lagi kata pa eko, kalau ngeyel mau gimana lagi wkwkwk
begitulah, biasanya banyak alasan, padahal sebenernya males
Pengen tau pendapat mas Eko mengenai developers yang bersikeras "200 OK aja cukup". Menurut mas Eko, kenapa bisa terjadi seperti itu dan bagaimana cara kita bisa mengubah pola mindsetnya ? Apakah ini bawaan dari gaya lama (SOAP, ISO8583) , keren sih mas Eko kalau bisa dibahas.
Anyway, Channel mas Eko keren banget, video barunya selalu gue tunggu. Keep it up mas !
ada 2 alasan
- kebiasaan pake SOAP, yang selalu 200 OK
- ngeyel
Kalo dari sudut pandang ini:
Http status adalah sebagai penanda apakah:
1. server berhasil mengembalikan response (200)
2. atau server gagal kesalahan di server (500)
3. atau url server tidak ditemukan / salah url (404)
*seperti di video dibilang 4xx sebagai problem di sisi client
Sedangkan untuk informasi bahwa produk ditemukan ataupun tidak ditemukan, server berhasil mengembalikan informasi itu sebagai "response" dari server, sehingga tetap dikirimkan sebagai "response" berhasil http status 200 ke client.
@@oantech sepertinya mas eko ini emang termasuk programmer yg detail sih termasuk soal http response...
Kayaknya dari semua kode respon yg paling sering jd debat mungkin soal 404 ya... 😂
Secara harfiah artinya memang not found, tapi bener kata mas eko, kode 4xx itu kesalahan client, dan kasus tidak menemukan hasil pencarian bukanlah sebuah kesalahan client.
Jadi 404 harusnya memang tidak untuk merespon hasil yg "kosong" seperti search atau kategori yg kategorinya ada tapi itemnya kosong (tetap 200).
404 digunakan lebih ke "tujuan langsung" yg tidak ada seperti nembak langsung ke id tertentu meskipun melalui request body, jadi tidak hanya masalah endpoint/url yg tidak ditemukan...
kalo dari saya yg memang di front end yang menggunakan ReactJS, itu kerasa banget. karena ketika pake async await yang menggunakan then sama catch atau try catch, ketika response nya error tapi status nya 200, itu jadi gk masuk ke kondisional catch nya, dan itu nyebelin karena jadi gk clean code, kebanyakan conditional di then atau try nya.
Mungkin kalo untuk data yg tidak ditemukan, dan secara response informasi ini berhasil dikembalikan oleh server, bisa kita gunakan 204 No Content 😁
Ini bukan "ngeyel", ini open diskusi 😂😂
Hahahaha... Setelah liat video ini, saya sadar bahwa saya tidak ngeyel.
Selama ini saya yg disebut ngeyel oleh tim 🥺
besok dimusuhin sekantor
@@ProgrammerZamanNow hahahaha... Sudah 3 tahun lebih beda pendapat. Sudah biasa. Saya nyerah, makan gaji doank, sambil browsing kerjaan.
Ud mau kepala 4 susah bersaing sama yg muda2 😆
Permisi pak eko, saya baru saja mempelajari tentang hexagonal architecture dan ingin mengimplementasikannya pada project saya menggunakan bahasa pemrograman java. Dari yang saya pelajari, di dalam arsitektur ini, layer yang berisi domain object/entity harus dibuat independen (tidak bergantung pada dependency lainnya). Pertanyaannya adalah apakah saya boleh menggunakan dependency lombok pada layer yang berisi domain object/entity untuk mengurangi boilerplate code ?. Terima kasih.
pertanyaan mengganjal saya selama ini, terjawab dengan gamblangnya, thanks pak eko
mantap materinya Mas, sudah lama jadi perdebatan dengan teman teman mengenai ini
Semoga bermanfaat
Mantap... Terimakasih pak Eko, kebetulan jg lagi bingung bikin response yg baik
Semoga membantu ya
hmm kalo saya sedikit setengah2 soal metode nya mas eko, menurut saya http status code itu emang harus di bedakan, nah kalo saya membedakannya untuk error2 yang berkaitan sama status endpoint bukan berkaitan sama data, contoh: 404 digunakan untuk endpoint yang jelas2 ngga ada, 400 bad request digunakan untuk request2 yang tidak normal. 401 untuk otorisasi, sedangkan untuk status yang berkaitan dengan data prosesing atau data fetching biasanya saya tetep kirim 200 walaupun data yang di cari tidak di temukan, dan saya kasih properti code, misalnya 1062 untuk code duplicate, dan properti ini biasa saya gunakan untuk mengkategorikan response diluar status http. cmiiw mas
UP gan
Utk 404 kebetulan hampir sama, saya pake 404 ketika salah endpoint atau query by ID (ID yg diambil dari list utk lihat detail, karna absurd, di list muncul masa ketika lihat detail ga ada, maka itu saya anggep error a.k.a. 404 a.k.a. ada yg ga beres sama backend nya), tapi ketika query by name atau apapun yg diinput user (e.g. alamat, nama produk, nama konsumen, dsb), saya balikinnya 200, kalo balikinnya 404, wadaww, log isinya penuh sama 404.
CMIIW juga pak Eko.
Saya juga sepemikiran
masukan aja om, untuk konsistensi response itu ga perlu dimasukkan ke attribute data atau sejenisnya. konsisten itu nama attribute dan data typenya tidak berubah. sekali2 main ke open APInya nasa, google, twitter, dll
memang, gak wajib pake data, itu cuma saya contohkan aja
@@ProgrammerZamanNow okok, soalnya sering terjadi perdebatan antara fe dan be disitu hehe
saya pake c# asp net core,belajar tutornya di udemy, brrti saya udah bener sesuai dengan kang eko response APInya 😀😁
wah kalau semua backend nerapin ini, pasti kita anak F.E bisa lebih ceria dan muka kita lebih muda 10 tahun
Setuju, mungkin lebih tepatnya kalo akses api langsung via url (tanpa request body) dengan method GET/PUT/DELETE maybe, nahh case ini bisa pakai 404 untuk response kalo memang tidak ditemukan datanya. Ini karena proses manggilnya hanya dengan url (maksudnya paramnya ada d url atau queryString), makanya masih sejalan dengan kegunaan http error 404 not found. Kenapa, karena seakan2 mau akses url yg mana dibentuk juga dengan queryString di paramnya, yang mana secara data juga memang tidak ada.
Cuman misalnya prosesnya pakai request body (misalnya metode POST), disini agak tricky karena secara url itu adalah loh handlernya jadinya menurutku lebih baik handle pakai 200 dengan sebutin errornya d body responsenya.
koreksi yaa kalo beda pemahaman.
kalo url benar, tp data tidak d temukan pake 204 (no content)
@@ahmadkholil9972 Setuju, dan memang kalo secara kaidah http code memang ada banyak dan sudah ada fungsinya masing2 sih, tinggal handle d consumernya aja.
Cuman saran aja, kalo consumernya internal tim juga, misalnya tim FrontEnd satu perusahaan, yaa mending kesepakatan aja biar memudahkan dan lebih cepat fase developmentnya.
Kalo diexpose sebagai OpenAPI, mungkin bisa jadi lebih baik pakai http code standar. Dan ingat dokumentasinya jadi mesti lebih komplit juga.
pak saran ndonk, bikin kan github/apiary atau apapun buat dokumentasi nya ini
Terima kasih Mas Eko atas ilmunya, mau tanya kepada Mas Eko dan temen-temen sekalian. kalo utk naming key sendiri itu best practicenya pake lowerCamelCase atau lowercase_with_underscore ya?
terima kasih
Bebas kalo itu, tapi biasanya krbanyakan camelCase
@@ProgrammerZamanNow ok makasih mas 🙏🏼
API yang saya bikin saat ini pukul rata 200 semua. Sangat membuka pikiran. Next pengen saya benahi.
Menertawakan diri sendiri. Wkwkwk.
Pake laravel enak banget kalo buat response validation kaya gitu 😆
Betul, buat backend enak bgt..
baru sadar sekarang setelah nonton ini.. rupanya itu alasan kenapa response dari laravel , kolom id atau kolom nama kok tipe nya array. rupanya karena error dalam satu kolom itu gak mungkin satu ya.. terimakasih mas eko..
saya termasuk yang ngeyel untuk buat status kode.. main hajar aja.. bahkan kode nya buat 2 digit. seperti "00" "40", "33", ngasal
Mantap materinya..
request tutorialnya bang, apalagi API di level enterprise dan integrasi2 yg umum dilakukan
Kang, kira-kira pada laravel atau web project ini perlu strings resource tidak? dengan tujuan untuk memudahkan pembuatan localization dikemudian hari dan dengan strings resource juga lebih membuat rapih kode dan meminimalisir redundan string message yang sama. Apakah ini efektif?
Perlu donk
Kalo saya sih selalu buat 😁
@@kudriabdulnaim7660 string resource yang kaya gimana bang contohnya?
@@ProgrammerZamanNow nah saya juga saat ini menerapkan, cuman strings resourcenya kalo di laravel itu extensionnya kan php, bukan json. Jadi untuk penerapan di php dan blade itu tidak ada masalah, mudah dan dapat autosuggest variablenya di vscode. Tapi untuk penerapan di file JS itu saya belum tau cara penerapan seefektif di file php atau blade, semudah pakai __('{string_name}'). Saya coba akalin dengan cara simpan jsonnya ke dalam variable global pada dalam file bladenya. Cuman saya rasa itu kurang efektif, mungkin disini ada yang punya solusi efektifnya, terima kasih sudah merespon kang.
String resource apa ya ? Apakah json yg di lang ?
Sangat bermanfaat. terima kasih Pak
ngomong2 monitoring tools, biasanya pake apa mas untuk monitoring server sama aplikasinya?
di tempat saya pake zabbix cuma menurut saya item2nya kurang greget
Kang, tolong bahas circuit breaker di microservice 🙏🏼
terimakasih pak eko ilmunya, sangat bermanfaat
Kang Eko, misi nih, saya mau nanya tentang bagian yang pagination, maaf ya kawan kalau udah ada yang nanya dan saya ga liat
Nah untuk pagination gitu enak nya tiap pindah page, API nya request lagi, atau diolah di frontend nya Kang?
bantu jawab, harusnya tiap pindah page api request lagi, kalo dari backend ngelempar semuanya dan diolahnya di frontend itu akan terasa berat loadnya
@@sgh7234 oooh, jadi begitu Kang tujuan dari attribute page d API nya, baik kalau begitu Kang, terima kasih atas jawabannya, sangat membantu🙏
request lagi
@@ProgrammerZamanNow siap Kang, terimakasih atas jawabannya
Mas eko, sample response untuk tag page nya untuk nampilin next prev data gimana? sesuai informasi request penggunaan halaman pada data taransaksi kan lambat, UX di client bisa load next data sebelumnya dan pull up data setelahmya
kalo paging nya pake token, tinggal di object page tambahin attribute nextToken dan prevToken
Terima kasih atas ilmu nya pak, sangat membantu sekali dalam memahami response dalam membuat sebuah API, kadang saya suka bingung sendiri dalam mengembalikan response dari API kepada user karena tidak begitu memahami best practice dalam membuat response API tersebut. Namun saya ingin bertanya pak, jika data tidak ditemukan dan kita mengembalikan response 404, lalu bagaimana dengan response 204 pak? mohon penjelasannya pak, terima kasih
Kalo 204 ini biasa dipake untuk request delete dari request, yang artinya request berhasil namun content-nya sudah tidak ada krn dihapus.
Beda antara 404 dan 204, kalo 404 itu datanya memang tidak ada, sedangkan 204 itu datanya sudah dihapus tapi request-nya berhasil.
Mantap banget nih materinya
perusahaan software tinggi Indonesia mana sih bang, setinggi cara loe ngejelasin ?
yg sllu gue denger disini cuma: "kalau kalian mau jadi kacung sejati kapitalis, harus gini, harus gitu"
bukannya Negeri ini krisis skill IT ?
artinya, bahasa anak SD jauh lebih mudah dicerna dan lebih berguna. khususnya bagi org sprti saya.
saya yakin, bahasa sederhana yg konkret tidak akan mengurangi wibawa abang sebagai Guru & Senior.
Semoga para IT dinegeri ini lebih baik lagi.
Backend ku harus lihat ini....
terima kasih ilmunya pak Eko
akhirnya ada video penjelasan.
biar gak berantem
Sangat bermanfaat pak.
jadi selama ini saya salah membuat response API, thanks ilmunya
tinggal perbaiki
Saya punya case yg sama. Casenya status code 2xx untuk post data dalam bentuk bulk (lebih dari 1 data). Di setiap data belum tentu berhasil untuk disimpan ke DB dan tiap data punya spesifikasi response yg berbeda. Ada data yg berhasil disimpan ada jg yg gagal. Tapi semua itu dalam 1 response yg sama dan akhirnya memutuskan untuk menggunakan status code 2xx dengan bentuk data array yg setiap datanya memiliki message sukses atau gagal. Kalau case seperti ini kira2 udah proper apa blm kalau menggunakan status code 2xx mas Eko?
terimakasih pak Eko ilmunya, selama ini saya masuk kategori 'ngeyel' hahahhah
kalau masalah localization misal web kita punya capability ditampilkan dalam beberapa bahasa. apakah untuk error nya dari api tetap english atau sudah di translate? atau lebih baik di frontend nya di translate satu satu berdasarkan string error responsenya?
Dari API nya sudah di translate, jadi Frontend ketika request bisa ngirim di Headers "localization":"id" yg bakal di olah BE.
Jadi, kasus di atas, di translate di BE
bagusnya dari BE bisa support multi bahasa juga
Terimakasih pa eko atas jawabn nya.
12:19 Payment gateway musti nih 🤣🤣🤣
Terima kasih udah sharing mas
True story dan akhirnya berdamai antara BE dan FE kalau result & error rapi gini
Sorry saya punya pendapat lain, 404 itu untuk URI yang tidak terdaftar di route rest api. Untuk data kosong itu 204 (no content)
Wah saya jadi bingung lagi 😂, masuk ke 2xx berarti tidak error
204 itu kalo mau response ke client tapi gamau ngirim apa2
Di tempat sekarang saya sebagai android dev dikasih responsenya pake echo json.encode() pak, itung-itung belajar sabar hahahaha
Awowkowwkok, kenapa gak json sekalian tuh?
@@adbc5535 "itu responsenya json" jawab tim backend wkwk
@@rizaldian4067 Atau di header androidnya dikasih header content type aplication/json mas, bisa gak ya?
@@adbc5535 Saya coba set header sebelum echo aman nih, baru kepikiran juga, thanks cluenya #LOL
@@rizaldian4067 Set header nya di backend mas? bukan di androidnya?
No virus, real work
Misalnya ada API untuk ambil list data tapi dari FE pengennya kalo datanya kosong itu balikkannya tetep 200 biar ga kena page not found, padahal secara teori harusnya 404, menurut Mas Eko gimana?
bukannya memang status balikannya ttp 200 y kl req list data dgn balikan empty array, krn secara teknis yg dreq itu berupa collection of data (array), bukan spesifik datanya. Beda dgn kl kita get product by id, kl datanya gak ada baru bs dbalikin dgn code not found, krn emang resourcenya itu gak ada, kl empty array itu kn ttp ada resourcenya, yaitu array (walaupun isinya kosong). cmiiw
kalo search data, gak nemu ya tetep 200, tapi kalo get data by id, gak nemu, ya 404
@@steffenlaurens8280 oalah, makasih penjelasannya mas
@@ProgrammerZamanNow kalau get by id tapi salah endpoint gimana mas?
kalo gua pribadi untuk 404 ini gak gua pake sama sekali, itu dibiarkan sama seperti 500, biar system yg atur, jd ketika fetch data tidak ditemukan, gua tetep akan kasih respon 200 dengan structute
message : data not found
data : null
kenapa gua pake 200, tujuan nya ada FE jg mudah identifikasi apakah url yg dituju sudah sesuai apa tidak, karena akan muncul 2 fikiran,
apakah url yg dituju bener / tidak?
pengalaman gua sih gitu, makanya tetep pake 200 tp mainin di respon body
biar gak ambigu aja terkait url nya
tergantung kesepakatan aja sih
saya udah sering integrasi dengan api service provider dari china
hampir sebagian besar return http status codenya mau sukses atau nggak ya 200 😂
Harus diluruskan kalo gitu orang china nya
better yang di body itu aplication exit code ngga si bang..
misal mysql error kan dia nanti return exit code biasanya,, walaupung ngga penting si buat front end
Sharing komparasi APM berbayar mas, misal dynatrace, new relic, elastic, splunk, etc.
Tiap produk pasti ada pros and cons.
belum pernah pake semua, cuma pake yang dipake di tempat kerja aja
@@ProgrammerZamanNow pake prometheus ya pak?
Mantap pak
Jika ada api menghapus multiple id, beberapa id tidak ada di db,berhasil hapus dan gagal hapus, itu response code yang cocok apa? dan return array datanya apa ya?
Kyknya yg perlu diperbaiki aplikasinya bro... Kan ada validasi dulu memastikan id nya ada, setelah itu pakai db transaction atau semacamnya, jd ga ada operasi sebagian success sebagian failed...
Tapi kalau emang terpaksa, kayaknya pakai http 5xx
kalo hapus multiple, idealnya dikasih tau mana yang sukses mana yang gagal, biar FE tau mana yang gagal dihapus
@@MargaRizaldiChannel Iya mas, sekarang sudah di check dulu datanya ada apa tidak, masih bingung di responeBody nya, jika per requeat ada id yang datanya tidak ada/gagal/berhasil hapus mas
@@adbc5535 tapi btw bener balasan mas eko sih kasitau yg berhasil mana yg gagal mana... Responnya kasih 200 aja g usah terlalu dipusingin, nanti klo ada yg komplain tinggal tanya maunya respon berapa
@@MargaRizaldiChannel Kode response nya, ikut anak FE nya mas?
Pengalaman saya, para developer memang suka debat di situ pak Eko, ranah datatable. Misal ada search by keyword, terus data dengan keyword tersebut gaada.
Katanya status codenya tetap 200, toh pencariannya tetap berhasil hanya saja isi arraynya 0. Sampai skrg gatau mana yg bener, saya ngikut aja asal konsisten
Kalo itu benar, 200
tetep 200 gan, request nya g ada yg salah, return nya aja yg empty, bukan null
Ternyata mas Eko mengalami hal yg sm dgn sy khsususny sbg Kotlin developer xD
semua programmer pasti ngalamin
Kadang bikin cuma "OK" sama "ERROR" doang, mau ideal ga bisa gara2 antara deadlinenya 1jam abis breafing langsung jadi atau clientnya ga ngerti json dijaddinn response body dan tidak mau tau soal json tsb
Makasih pak eko , pas banget lagi bikin response tapi bingung best practice nya
Terimakasih pak eko
daging🤤makasih pak eko
Mantap mas, terimakasih ilmunya
Semoga bermanfaat
Saya Backend Developer, saya juga suka dengerin content mas Eko,
tapi saya tidak setuju dengan balikan dari httpstatus 404 untuk item not found.
Bagaimana cara kamu membedakan itu masalah di endpoint atau item not found?
masalah salah endpoint itu urusan client, mirip kayak misal rumah saya di jakarta, trus orang datang ke bandung, bukan urusan saya orang nya nyasar ke bandung, karena rumah saya di jakarta
@@ProgrammerZamanNow betul karena server(backend) gak bisa maksa client untuk memasukan data sesuai yg diinginkan oleh server, makanya ada sistem validasi.
server gak ngurusin kesalahan client misal salah endpoint dll, tugas server itu untuk memastikan data yg diinput valid. kalo gak valid ya balik lagi ditolak dgn http response yg sesuai
@@ProgrammerZamanNow btw mas eko bahas soal BaaS dong supabase atau appwrite
keren kie kang
First pak Eko
Terima kasih video nya pak Eko, kebetulan di kantor saya sedang ada issue serupa yang pak Eko bahas.
Sebelumnya kita set apabila ada kondisi not found data itu status code nya 404, namun saat kita cek menggunakan monitoring graylog / sentry maka hal tsb menurunkan success rate dari API tersebut (krn dianggap tidak success), padahal data tidak ditemukan adalah bagian dari flow koding (expected flow). Dan dari kantor ada standart API aplikasi successrate itu harus 90%.
Akhirnya kita merubah status code menjadi 200 dan validasi diarahkan ke body response, apabila kosong/empty maka lanjut ke logic tertentu. Dengan spt ini API success rate menjadi naik.
Dengan kondisi spt ini, menurut mas Eko apakah standart success rate nya memang perlu dikaji ulang atau bgmn kira2 kebijakan yang lebih baik/best practice saat menggunakan tools monitoring?
Saya sih, kalau data yang di cari kosong ya tetap 200 kecuali server error 5xx atau client error 4xx kalau 404 itu dipake ketika path urlnya ga ada
@@boniedwin trims insight nya gan!
kalau di saya, data array kosong masih masuk code 200, kalau data single kosong / tidak ditemukan di db, status code 400++ dengan error seperti: "id invalid", dll.
wkwkwk, lagi ngalamain ini baru banget, susah emang adu argumen sama yang coding android. pengennya 200 terus wkwkwkwk
Tusuk bang matiin
Ganti mobile dev baru
Wkwkwkwk justru seharusnya kalau ga 200 malah ribet, soalnya ga ke baca di try catch
@@boniedwin jujur g tau kalau d android emang harus 200 yak. Soalnya w juga baru integrasi sama android
Bagian ini sering saya ulang-ulang 😁😁
Loncat ke menit 09:07
Bayangkan kalo kita sama sekali gak balikin response 500, cuma 200 aja semuanya, jadi dianggapnya sukseeeeeess aja, gak ada apa-apa
kalau misal return dari data nya array dan isinya ga ada. misal array [ ] kosong. apakah ini bisa di kategorikan 404 juga? atau seharusnya tetap 200 karena request nya berhasil, cuman datanya aja yg masih kosong. soalnya lihat beberapa implementasi yg ngereturnya 404 kalau data list returnya masih [ ]
Tetep 200, tapi empty array
saya sendiri biasanya tergantung apa yang dilakukan, kalau didalam request saya harus mencari specific data, biasanya bakal 404 kalau ga dapet kalau all data tetep 200
Klo menurut saya ketika data blm ada isinya harusnya tetep status 200. Begitu juga kasus filtering return nya 200, walaupun datanya gak ada. Status 404 lebih mengacu ke data id yg invalid / api path nya salah.
jadi untuk kasus filtering/spesifik jika tidak ketemu best practicenya status code 404 atau 200?
Saya juga mikir nya harusnya 200 sih. Tapi for some reason qa di tempat saya mintanya harus 404
Mantab
Gimana negur nya ya ke backend mau success mau error tetap 200, gw di frontend klo ada error sulit traking nya, di backend cuman return error true sama message
Http status selalu 2xx ini saya alami saat consume api dari bp*s..dari awal saya udh nanya kenapa kalau error malah responsenya 201..
akhirnya saat integrasi dgn mereka,saya jg harus menyesuaikan error kodenya jadi 201 kalau error
Bukan nya 201 respon berhasil bg... Kmi justru di minta org bpjs. 😂😂.... Blum lagi jkn mobile y sering bermasalah...
mantapp pak
saya pernah ketemu response API yang setiap field datanya dipisahkan tanda bintang... cukup amazing.
sample nya seperti ini..
"data": [
"SUMATERA UTARA*KAKAO*ASAHAN*ANTRAKNOSA (COLLETOTRICHUM GLOEOSPORIOIDES)*1,476.23*260.94*112.28*27,428.57*10,091.81",
"SUMATERA UTARA*KAKAO*ASAHAN*HELOPELTIS SP.*1,476.23*253.88*98.14*27,428.57*8,821.61",
]
apakah tmen2 ada yang pernah ketemu dengan respons API yang sperti ini... ?
Pernah, pakai delimeter pipe |
BE nya mungkin males/ga paham suruh kita string split sendiri
anjay ibarat customer mesen makanan, disampein ke koki dari pelayan, pas pelayan balik disuguhin bahan nya doank + pesen dari kokinya "Olah sendiri yak"
@@2manasama iya om, sy coba sampaikan baik2 sama dev nya.. malah sy di framing negatif di hadapan para peserta meeting...
** ini proyek takeover dari vendor langganan di dinas pertanian..
blm pernah mas, teraneh semuanya status code 200 padahal error, ini sih udah diluar nalar sih dipish dengan * :( apa pemikiran yg ngembangin balikan kaya gini
Bodoh banget itu developer
Api yang baik itu bisa di baca
Parameter nya apaan aja
Kalau di split string berdasarkan *
Itu sungguh kebodohan
Lu mesti cari tau dulu tiap isi string nya apaan
Ini mah modal jadi doank, dev nya bodoh
when github copilot actually helps you in the middle of recording wkwk
Mantap pake eko
apa cuma saya aja yang di sini kalo lihat video jadi gagal fokus, karena pantulan lampu di kacamata mas eko?
kalau status code validasi baiknya 400 atau 422 pak Eko ?
Terima Kasih
400 untuk validasi soalnya 422 untuk unprocessable entity
Tutorial buat ngasih detail error dan pagination di java boleh tuh 😅
izin bertanya, brrti validasi data request ribetpun gpp mas ya?
klw misalkan mau ngasih informasi yg details di error message nya
iya, gpp
@@ProgrammerZamanNow ty jawabanny mas
Bang kan beda tipe gak boleh.. trs kalo tiba-tiba data dari backend null itu boleh apa nggak ??
null sih gak masalah, berarti datanya emang kosong
Kalau produk tidak ditemukan harusnya bener 200, krna requestnya bener, cuman krna g ada doank, kecuali path nya yg tidak ditemukan, baru deh 404,
sama seperti search di web kalo data g ada ya tetep 200, tp kalo path salah, baru 404,
404 itu url not found, bukan data not found
CMIIW
Masalah paging, if only para backend developers mengerti soal ini T_T
Jika pesan error nya ingin multi bahasa, bagaimana best practice nya mas?
apakah dengan header Accept-Language atau bagaimana?
bikin key aja bro, misal: en atau id
orang-orang yg return message error pake HTTP 200 itu orang yg fixed mindset