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:

🔗 github.com/jacky-htg/workshop/tree/main/12-standard-response

12.1 Masalah dengan Response Tidak Terstandar

Response sukses saat ini:

// 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:

  1. Standard Response Pattern – Format JSON seragam untuk semua endpoint

  2. Business Status Code – B1 (sukses) dan B0 (error)

  3. Helper Functions – SetOk(), SetCreated(), SetError() untuk konsistensi

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

Last updated