Cara Membuat REST API Sederhana dengan FastAPI

Data yang terkunci di satu aplikasi hanya berguna untuk aplikasi itu. Begitu diberi API, data yang sama bisa dibaca aplikasi kasir, dashboard pemilik, dan workflow otomasi sekaligus. REST API adalah pintu standarnya, dan FastAPI membuat pintu itu bisa berdiri dalam satu sesi kerja — lengkap dengan validasi data dan dokumentasi yang menulis dirinya sendiri.

Kenapa FastAPI jadi pilihan default Python

Tiga alasan yang bertahan setelah dipakai bertahun-tahun di proyek kami: kecepatan pengembangan (endpoint adalah fungsi Python biasa dengan type hint), validasi otomatis (data yang salah bentuk ditolak sebelum menyentuh logika Anda), dan dokumentasi interaktif yang selalu sinkron dengan kode karena dibangkitkan dari kode itu sendiri. Untuk tim kecil, poin ketiga saja sudah menghemat berhari-hari kerja dokumentasi manual.

Langkah 1: Siapkan proyek dan virtual environment

Python punya kebiasaan baik yang wajib dipertahankan: satu proyek, satu lingkungan terisolasi. Di terminal:

mkdir api-toko && cd api-toko
python3 -m venv .venv
source .venv/bin/activate
pip install "fastapi[standard]"

Di Windows, baris ketiga menjadi .venv\Scripts\activate. Paket fastapi[standard] sudah menyertakan server pengembangan, jadi tidak ada lagi yang perlu dipasang untuk memulai.

Langkah 2: Tulis endpoint pertama

Buat file main.py:

from fastapi import FastAPI

app = FastAPI(title="API Toko")

produk = [
    {"id": 1, "nama": "Kopi Arabika 250g", "stok": 40},
    {"id": 2, "nama": "Kopi Robusta 250g", "stok": 12},
]

@app.get("/produk")
def daftar_produk():
    return produk

@app.get("/produk/{produk_id}")
def detail_produk(produk_id: int):
    for p in produk:
        if p["id"] == produk_id:
            return p
    return {"error": "produk tidak ditemukan"}

Jalankan dengan fastapi dev main.py, lalu buka http://127.0.0.1:8000/produk. Perhatikan detail kecil yang bekerja untuk Anda: parameter produk_id: int membuat FastAPI otomatis menolak /produk/abc dengan pesan error yang jelas — validasi yang tidak Anda tulis sebaris pun.

Langkah 3: Validasi data dengan Pydantic

Endpoint yang menerima data (POST) adalah tempat validasi paling dibutuhkan. Definisikan bentuk datanya sebagai model:

from pydantic import BaseModel, Field

class ProdukBaru(BaseModel):
    nama: str = Field(min_length=3, max_length=100)
    stok: int = Field(ge=0)

@app.post("/produk", status_code=201)
def tambah_produk(item: ProdukBaru):
    baru = {"id": len(produk) + 1, "nama": item.nama, "stok": item.stok}
    produk.append(baru)
    return baru

Kirim stok negatif atau nama satu huruf, dan FastAPI membalas error 422 yang menyebut persis field mana yang salah dan kenapa. Kontrak data yang tegas di gerbang seperti ini mencegah kelas bug yang paling melelahkan: data kotor yang lolos masuk dan meledak jauh di dalam sistem, berhari-hari kemudian.

Langkah 4: Baca dokumentasi otomatis di /docs

Buka http://127.0.0.1:8000/docs. Semua endpoint Anda sudah terdaftar, lengkap dengan bentuk request dan response-nya, dan bisa dicoba langsung dari browser — tombol "Try it out" mengirim request sungguhan. Untuk kerja tim, halaman ini mengubah percakapan "field-nya apa saja?" menjadi "buka /docs". Dokumentasi yang dibangkitkan dari kode tidak pernah basi.

Dari contoh ke produksi: yang masih kurang

Supaya jujur terhadap batas tutorial ini: daftar produk di atas hidup di memori dan hilang tiap restart. API sungguhan masih membutuhkan beberapa lapisan lagi, dan urutannya kira-kira begini:

• Database menggantikan list Python — SQLite untuk mulai, PostgreSQL saat serius.
• Autentikasi — minimal API key untuk membedakan siapa boleh apa; tanpa ini API Anda milik umum.
• Penanganan error yang konsisten — kode contoh tadi mengembalikan status 200 untuk produk yang tidak ada; yang benar adalah 404 lewat HTTPException.
• Server produksi di belakang reverse proxy dengan HTTPS, bukan server development.

Kalau kebutuhan Anda berhenti di "alat internal yang dipakai lima orang", FastAPI plus SQLite di satu VPS kecil sudah lebih dari cukup. Kalau yang dibangun adalah sistem yang dipakai pelanggan membayar, tiap lapisan di atas menjadi wajib — dan di titik itu menimbang menyerahkannya ke tim yang mengerjakan ini tiap hari adalah hitungan bisnis, bukan gengsi teknis.

Langkah wajar berikutnya: sambungkan API Anda ke database sungguhan, lalu biarkan sistem lain memakainya — termasuk workflow otomasi seperti yang kami tunjukkan di integrasi n8n dan Google Sheets. Butuh diskusi arsitektur? Hubungi kami.