For the complete documentation index, see llms.txt. This page is also available as Markdown.
Standard Response
Saat ini, API kita mengembalikan response yang tidak konsisten:
Saat sukses → mengembalikan JSON data mentah (array user atau object user)
Saat error → mengembalikan teks biasa melalui http.Error()
Hal ini menyulitkan client (mobile, frontend) dalam memproses response karena struktur yang selalu berubah. Bab ini akan membangun standard response yang seragam untuk semua endpoint.
📂 Kode Lengkap Bab Ini:
Seluruh kode yang dibahas di bab ini tersedia di GitHub:
// GET /users[{"id":"123","name":"John",...}]// POST /users{"id":"456","name":"Jane",...}
Response error saat ini:
Internal Server Error
Masalah
Dampak
Tipe data berbeda
Sukses → array/object, Error → string
Tidak ada status business logic
Client tidak tahu apakah operasi benar-benar sukses
Tidak ada pesan yang konsisten
Frontend sulit menampilkan error message
12.2 Desain Standard Response
Kita akan mendefinisikan format response JSON yang seragam:
Field
Deskripsi
Contoh Nilai
status
Status business logic (bukan HTTP status)
"B1" (sukses), "B0" (error)
message
Pesan yang ramah untuk user
"User created successfully"
data
Payload data (bisa object, array, atau null)
{"id": "123", ...} atau [] atau {}
Mengapa status business logic? HTTP status code (200, 400, 500) untuk infrastruktur. Status "B1"/"B0" untuk logika bisnis. Contoh: login gagal karena password salah → HTTP 200 (request berhasil diproses) tapi status "B0" (business error).
12.3 Implementasi Response Helper
Buat file pkg/response/response.go:
12.4 Refactor Handler Menggunakan Response Helper
Sekarang semua handler diubah menggunakan helper di atas. Kode menjadi lebih bersih dan konsisten.
UserHandler.List
Sebelum:
Sesudah:
UserHandler.Create
Sebelum:
Sesudah
UserHandler.FindById
Sebelum:
Sesudah :
12.5 Kode Lengkap Handler yang Direfactor
12.6 Contoh Response Setelah Standardisasi
Response Sukses (GET /users)
Response Sukses (GET /users/{id})
Response Sukses (POST /users)
Response Sukses (DELETE /users/{id})
Response Error (User Not Found)
Response Error (Invalid Request)
12.7 Manfaat yang Diperoleh
Sebelum
Sesudah
Response tidak konsisten
Semua response memiliki format seragam
Error berupa teks biasa
Error juga dalam format JSON
Kode repetitive (Marshal + Header + Write)
Satu baris SetOk() atau SetError()
Status business logic tidak ada
Status B1/B0 untuk logika bisnis
Perubahan format susah
Cukup ubah satu fungsi SetResponse()
Ringkasan Bab 12
Di bab ini kita telah belajar:
Standard Response Pattern – Format JSON seragam untuk semua endpoint
Business Status Code – B1 (sukses) dan B0 (error)
Helper Functions – SetOk(), SetCreated(), SetError() untuk konsistensi
Refactoring Handler – Kode menjadi lebih bersih dan mudah dipelihara
Manfaat yang kita peroleh:
✅ Frontend bisa memproses semua response dengan cara yang sama
✅ Error message informatif dan terstruktur
✅ Mudah menambahkan field baru ke semua response (misal: request_id)
✅ Mengurangi duplikasi kode (DRY principle)
Yang akan datang:
Saat ini error handling masih sederhana (semua error balik ke client dengan status B0)
Bab selanjutnya: Error Handler – membangun sistem error handling yang lebih canggih dengan custom error types dan proper error wrapping