Go Web API Lanjutan

Definisi

Setelah route & middleware dasar jalan, Web API produksi butuh kontrak error seragam, validasi request, dan strategi versioning agar klien tidak patah saat API berkembang.

Kapan dipakai

Pakai saat API mulai dipakai klien nyata (frontend, partner). Tanpa error format konsisten dan validasi, debugging dan integrasi jadi berat.

Cara kerja

Error response seragam

go

type ErrResp struct {
    Error string `json:"error"`
    Code  string `json:"code,omitempty"`
}
 
func writeErr(w http.ResponseWriter, status int, msg string) {
    w.Header().Set("Content-Type", "application/json")
    w.WriteHeader(status)
    json.NewEncoder(w).Encode(ErrResp{Error: msg})
}

Validasi struct

go

type CreateUser struct {
    Email string `json:"email" validate:"required,email"`
    Name  string `json:"name" validate:"required"`
}
 
// pakai github.com/go-playground/validator/v10
if err := dec.Decode(&u); err != nil { writeErr(w, 400, "bad json"); return }
if err := validate.Struct(u); err != nil { writeErr(w, 422, "invalid"); return }

Versioning via path

go

mux.HandleFunc("/api/v1/users", listUsers)
mux.HandleFunc("/api/v2/users", listUsersV2)

Struktur alur

Catatan implementasi

• Selalu set Content-Type: application/json sebelum encode.
• Jangan bocorkan detail internal di error (log di server, kirim pesan aman).
• Versioning: path (/v1) paling eksplisit; header Accept lebih halus tapi sulit di-debug.
• Gunakan status code tepat: 400 bad request, 401 unauthorized, 403 forbidden, 422 unprocessable, 500 server.

Kesalahan umum

• Error message bocor stack: informasi internal bocor ke klien.
• Validasi manual berulang: pakai library validator.
• Status code sembarangan: 200 tapi isi error membingungkan klien.
• Versioning tidak konsisten: /v1 dan /v2 bentuk beda tanpa dokumentasi.

Referensi terkait

• Go HTTP Server, Routing, Middleware, JSON API
• Go Middleware Chain: Logging, Auth, Recover
• Next.js Route Handlers, Server Actions, Caching/Revalidation