Begitu project Laravel mulai punya lebih dari satu consumer, format response tidak bisa lagi dibiarkan improvisasi per endpoint. API Resource menjadi cara paling aman untuk menjaga bentuk data tetap stabil.
Selain membuat JSON lebih rapi, resource juga membantu memutus hubungan langsung antara struktur database dan apa yang benar-benar perlu dilihat oleh client.
Definisikan kontrak data lebih dulu
Langkah awal yang penting adalah mendefinisikan bentuk response per resource. Misalnya, post tidak harus mengirim semua kolom database. Cukup kirim data yang memang dipakai oleh card list, detail page, atau editor.
Dengan pola ini, perubahan internal di model tidak otomatis mengacaukan kontrak API yang sudah dipakai oleh frontend.
Mulai dari payload yang dipakai client
- Bedakan data untuk list dan detail.
- Hindari mengirim relasi yang belum tentu dipakai.
- Buat nama field yang jelas dan stabil.
Gunakan resource collection untuk list endpoint
Resource collection sangat berguna untuk menyisipkan metadata seperti pagination, current page, atau total item tanpa mengulang struktur di setiap controller. Hasilnya lebih konsisten dan lebih mudah diandalkan.
Saya juga lebih suka menyusun nested relation secara eksplisit agar client tidak menerima data yang berlebihan.
Contoh resource yang tetap ringkas
class PostResource extends JsonResource
{
public function toArray($request): array
{
return [
'id' => $this->id,
'title' => $this->title,
'slug' => $this->slug,
'author' => [
'name' => $this->author?->name,
],
];
}
}Jaga stabilitas response saat API berkembang
Saat API sudah dipakai di banyak tempat, stabilitas lebih penting daripada kecepatan improvisasi. Menambah field baru biasanya aman, tetapi mengubah nama field atau struktur object harus dipikirkan matang.
Karena itu, resource sebaiknya diperlakukan sebagai public contract. Dokumentasi sederhana dan contoh payload akan sangat membantu tim frontend dan mobile.