Best Practice untuk Response API 

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

Ini yang ditunggu2! Pembahasan tentang tips dan best practice. Semoga kedepan banyak konten2 kya gini. 🤩👍

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 🔥

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)

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.

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

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.

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.

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..

Alhamdulillah kang dapet pencerahan, saya sering nampilin eror itu cuman message: tidak ditemukan. Sehat terus kang 🙏

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

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

Waktu itu karena masing baru di per apian, cara saya contek response api di blibli dan sampai sekarang saya pakai acuan itu.

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.

Daging banget materinya. makaasih pak eko sharingnya, fix auto benerin di project sendiri karna selama ini masih asal bikin response API wkwk

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 !

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.

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.

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...

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 😁

Hahahaha... Setelah liat video ini, saya sadar bahwa saya tidak ngeyel. Selama ini saya yg disebut ngeyel oleh tim 🥺

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

Mantap... Terimakasih pak Eko, kebetulan jg lagi bingung bikin response yg baik

pak saran ndonk, bikin kan github/apiary atau apapun buat dokumentasi nya ini

pertanyaan mengganjal saya selama ini, terjawab dengan gamblangnya, thanks pak eko

mantap materinya Mas, sudah lama jadi perdebatan dengan teman teman mengenai ini

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

Pake laravel enak banget kalo buat response validation kaya gitu 😆

saya pake c# asp net core,belajar tutornya di udemy, brrti saya udah bener sesuai dengan kang eko response APInya 😀😁

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

Kang, tolong bahas circuit breaker di microservice 🙏🏼

request tutorialnya bang, apalagi API di level enterprise dan integrasi2 yg umum dilakukan

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.

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?

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.

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

wah kalau semua backend nerapin ini, pasti kita anak F.E bisa lebih ceria dan muka kita lebih muda 10 tahun

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

API yang saya bikin saat ini pukul rata 200 semua. Sangat membuka pikiran. Next pengen saya benahi. Menertawakan diri sendiri. Wkwkwk.

Mantap materinya..

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

Sorry saya punya pendapat lain, 404 itu untuk URI yang tidak terdaftar di route rest api. Untuk data kosong itu 204 (no content)

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?

Sangat bermanfaat. terima kasih Pak

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

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?

terimakasih pak eko ilmunya, sangat bermanfaat

12:19 Payment gateway musti nih 🤣🤣🤣

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

Backend ku harus lihat ini....

terimakasih pak Eko ilmunya, selama ini saya masuk kategori 'ngeyel' hahahhah

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

jadi selama ini saya salah membuat response API, thanks ilmunya

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 😂

terima kasih ilmunya pak Eko

ngomong2 monitoring tools, biasanya pake apa mas untuk monitoring server sama aplikasinya? di tempat saya pake zabbix cuma menurut saya item2nya kurang greget

Di tempat sekarang saya sebagai android dev dikasih responsenya pake echo json.encode() pak, itung-itung belajar sabar hahahaha

Sangat bermanfaat pak.

Terimakasih pa eko atas jawabn nya.

akhirnya ada video penjelasan. biar gak berantem

Mantap banget nih materinya

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?

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?

when github copilot actually helps you in the middle of recording wkwk

Terima kasih udah sharing mas

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?

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

True story dan akhirnya berdamai antara BE dan FE kalau result & error rapi gini

Sharing komparasi APM berbayar mas, misal dynatrace, new relic, elastic, splunk, etc. Tiap produk pasti ada pros and cons.

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

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

Ternyata mas Eko mengalami hal yg sm dgn sy khsususny sbg Kotlin developer xD

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 [ ]

wkwkwk, lagi ngalamain ini baru banget, susah emang adu argumen sama yang coding android. pengennya 200 terus wkwkwkwk

Mantap pak

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

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... ?

Terimakasih pak eko

Makasih pak eko , pas banget lagi bikin response tapi bingung best practice nya

Mantab

No virus, real work

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?

Mantap mas, terimakasih ilmunya

keren kie kang

apa cuma saya aja yang di sini kalo lihat video jadi gagal fokus, karena pantulan lampu di kacamata mas eko?

pak kalo gini gimana? { "code": 404, "status": "Not Found", "message": [ { "field": "id", "message": [ "The id field is required.", "The id field must be a number." ] } ] }

mantapp pak

daging🤤makasih pak eko

Tutorial buat ngasih detail error dan pagination di java boleh tuh 😅

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?

Mantap pake eko

kalau status code validasi baiknya 400 atau 422 pak Eko ? Terima Kasih

izin bertanya, brrti validasi data request ribetpun gpp mas ya? klw misalkan mau ngasih informasi yg details di error message nya

Bang kan beda tipe gak boleh.. trs kalo tiba-tiba data dari backend null itu boleh apa nggak ??

mas eko bahas tentang grpc api dong

Masalah paging, if only para backend developers mengerti soal ini T_T

First pak Eko

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

Jika pesan error nya ingin multi bahasa, bagaimana best practice nya mas? apakah dengan header Accept-Language atau bagaimana?