REST API vs GraphQL: Kapan Harus Pakai yang Mana? (dengan Contoh Kode)

"Pakai REST atau GraphQL?" adalah pertanyaan yang sering muncul di awal proyek, dan sering dijawab berdasarkan tren, bukan kebutuhan sebenarnya. Artikel ini membahas perbedaan keduanya lewat contoh kode nyata, supaya Anda bisa memutuskan berdasarkan kasus pemakaian, bukan sekadar ikut-ikutan.

Masalah yang Coba Diselesaikan GraphQL

Untuk memahami kenapa GraphQL ada, kita perlu lihat dulu dua masalah umum di REST API: overfetching dan underfetching.

Overfetching: Dapat Data Lebih Banyak dari yang Dibutuhkan

GET /api/users/1

// Response — Anda cuma butuh nama & email untuk ditampilkan di navbar,
// tapi server tetap mengirim semua field
{
  "id": 1,
  "name": "Budi Santoso",
  "email": "budi@example.com",
  "address": "Jl. Merdeka No. 10, Jakarta",
  "phone": "081234567890",
  "date_of_birth": "1990-05-14",
  "bio": "...(500 karakter)...",
  "preferences": { ... }
}

Underfetching: Data yang Dibutuhkan Tersebar di Banyak Endpoint

// Untuk menampilkan halaman profil dengan post & komentarnya,
// Anda perlu memanggil 3 endpoint terpisah:
GET /api/users/1          // data user
GET /api/users/1/posts    // daftar post milik user
GET /api/posts/5/comments // komentar di tiap post, dipanggil berulang per post

Semakin kompleks tampilan halaman, semakin banyak round-trip request yang dibutuhkan — masing-masing punya latency-nya sendiri.

Bagaimana GraphQL Menyelesaikan Ini

GraphQL memakai satu endpoint saja, dan client yang menentukan persis field apa yang dibutuhkan dalam satu request:

POST /graphql

query {
  user(id: 1) {
    name
    email
    posts {
      title
      comments {
        author
        text
      }
    }
  }
}

Response yang dikembalikan persis sesuai struktur yang diminta — tidak lebih, tidak kurang:

{
  "data": {
    "user": {
      "name": "Budi Santoso",
      "email": "budi@example.com",
      "posts": [
        {
          "title": "Belajar GraphQL",
          "comments": [
            { "author": "Sari", "text": "Artikelnya bagus!" }
          ]
        }
      ]
    }
  }
}

Contoh Implementasi REST di Laravel

// routes/api.php
Route::get('/users/{id}', [UserController::class, 'show']);
Route::get('/users/{id}/posts', [UserController::class, 'posts']);

// UserController.php
public function show($id)
{
    return User::findOrFail($id);
}

public function posts($id)
{
    return User::findOrFail($id)->posts()->with('comments')->get();
}

Simpel dan mudah dipahami — inilah kekuatan utama REST. Setiap endpoint punya tanggung jawab yang jelas dan bisa diuji secara terpisah dengan mudah.

Contoh Implementasi GraphQL di Laravel (dengan Lighthouse)

// graphql/schema.graphql
type User {
    id: ID!
    name: String!
    email: String!
    posts: [Post!]! @hasMany
}

type Post {
    id: ID!
    title: String!
    comments: [Comment!]! @hasMany
}

type Query {
    user(id: ID! @eq): User @find
}

Dengan skema ini, client bisa meminta kombinasi data apa pun yang mereka butuhkan tanpa Anda perlu membuat endpoint baru untuk setiap kombinasi tampilan.

Perbandingan Langsung

Aspek	REST	GraphQL
Jumlah endpoint	Banyak, satu per resource	Satu endpoint untuk semua
Kontrol data	Ditentukan server	Ditentukan client
Caching HTTP	Mudah (standar HTTP cache)	Butuh setup tambahan
Kurva belajar	Rendah, sudah familiar	Lebih tinggi, konsep baru
Cocok untuk	API sederhana–menengah, publik	Tampilan kompleks, multi-platform

Kapan Pilih REST

• API yang akan dipakai publik luas atau pihak ketiga — REST lebih universal dan mudah didokumentasikan (Swagger/OpenAPI).
• Proyek dengan tim kecil yang butuh sesuatu yang cepat dibangun dan dipahami semua orang.
• Kebutuhan caching di level HTTP (CDN, browser cache) yang jauh lebih matang di ekosistem REST.

Kapan Pilih GraphQL

• Aplikasi dengan banyak platform (web, iOS, Android) yang masing-masing butuh kombinasi data berbeda dari sumber yang sama.
• Tampilan dashboard kompleks yang menggabungkan banyak jenis data sekaligus dalam satu layar.
• Tim frontend yang sering berubah kebutuhan datanya tanpa ingin bergantung pada tim backend membuat endpoint baru tiap kali.

Kesimpulan

Tidak ada yang "lebih unggul" secara mutlak — keduanya menyelesaikan masalah yang berbeda. Untuk sebagian besar proyek company profile, katalog produk, atau sistem internal dengan kompleksitas menengah, REST API tetap pilihan paling efisien untuk dibangun dan dirawat. GraphQL baru benar-benar terasa manfaatnya saat aplikasi Anda sudah cukup kompleks dan multi-platform. Kalau ragu, mulai dari REST — Anda selalu bisa menambahkan GraphQL di kemudian hari untuk kasus spesifik yang membutuhkannya.