Alam Aby Bashit

Self-taught software engineer. 18+ years of IT and SDLC expertise.

Saat membaca requirement aplikasi web, kadang yang terlihat di permukaan hanya kalimat sederhana seperti:

“User bisa login, melihat data pelanggan, lalu mengubah status transaksi.”

Namun di balik kalimat itu, sebenarnya ada banyak keputusan teknis yang perlu dipahami. Ada komunikasi antara browser dan server, desain API, pemilihan database, aturan akses user, sampai cara sistem memastikan bahwa request benar-benar datang dari user yang valid.

Di sinilah fondasi web dan API menjadi penting.

Bukan supaya kita terlihat “lebih teknis”, tetapi supaya saat berdiskusi dengan tim, membaca requirement, membuat desain, atau membangun fitur, kita tidak hanya melihat tombol dan form. Kita juga memahami bagaimana data bergerak, bagaimana sistem menjaga keamanan, dan bagaimana aplikasi tetap bisa dikembangkan dengan rapi.

Artikel ini membahas beberapa konsep dasar yang sering muncul dalam project web modern:

  • Client-Server Architecture
  • API Design
  • REST APIs
  • Databases
  • SQL vs NoSQL
  • Authentication vs Authorization
  • Session-based vs Token-based Authentication
  • JWT

Saya akan membahasnya dari kacamata System Analyst yang sering harus menjembatani kebutuhan user, desain sistem, dan implementasi teknis.

1. Client-Server Architecture: Memahami Siapa Meminta Apa

Dalam aplikasi web, biasanya ada dua pihak utama: client dan server.

Client adalah pihak yang digunakan oleh user. Contohnya browser, aplikasi mobile, atau frontend web seperti React, Vue, Angular, atau Next.js.

Server adalah pihak yang memproses request, menjalankan business logic, membaca atau menyimpan data, lalu mengirim response kembali ke client.

Contoh sederhananya:

  1. User membuka halaman daftar invoice.
  2. Browser mengirim request ke server.
  3. Server mengambil data invoice dari database.
  4. Server mengirim data ke browser.
  5. Browser menampilkan data tersebut ke user.

Dari sisi System Analyst, konsep ini penting karena setiap requirement biasanya perlu diterjemahkan menjadi pertanyaan seperti:

  • Data apa yang perlu ditampilkan di client?
  • Aksi apa yang dilakukan user?
  • Server perlu memproses rule apa?
  • Data apa yang perlu disimpan atau diubah?
  • Response apa yang harus diterima user jika sukses atau gagal?

Misalnya requirement-nya:

“User dapat menyetujui pengajuan diskon.”

Di level client, mungkin ada tombol Approve. Di level server, ada validasi role, status dokumen, approval hierarchy, audit log, dan perubahan status. Di level database, ada update data approval dan mungkin insert ke history table.

Jadi, fitur kecil di layar bisa berarti proses yang cukup panjang di belakangnya.

2. API Design: Bukan Sekadar Endpoint Bisa Dipanggil

API adalah jembatan komunikasi antar sistem. Dalam aplikasi web, API sering menjadi penghubung antara frontend dan backend.

Namun API yang baik bukan hanya soal “bisa dipanggil”. API yang baik harus mudah dipahami, konsisten, aman, dan cukup jelas untuk digunakan oleh tim lain.

Contoh endpoint yang kurang jelas:

POST /processData

Endpoint ini membuat kita bertanya:

  • Data apa yang diproses?
  • Ini untuk create, update, approve, atau delete?
  • Response-nya seperti apa?
  • Error-nya seperti apa?

Contoh yang lebih jelas:

POST /api/invoices/{invoiceId}/approve

Dari URL saja, kita bisa menebak bahwa endpoint ini digunakan untuk menyetujui invoice tertentu.

Dalam API design, beberapa hal yang biasanya perlu diperhatikan adalah:

  • Nama endpoint mudah dipahami.
  • Method HTTP sesuai tujuan.
  • Request body jelas.
  • Response konsisten.
  • Error message membantu.
  • Ada validasi permission.
  • Ada dokumentasi.

Dari kacamata System Analyst, API design yang baik membantu requirement menjadi lebih konkret. Misalnya dari requirement:

“Admin bisa mengubah status customer menjadi inactive.”

Kita bisa mulai menurunkannya menjadi:

PATCH /api/customers/{customerId}/status

Dengan request body:

{
  "status": "INACTIVE",
  "reason": "Customer requested account closure"
}

Lalu response sukses:

{
  "customerId": 1001,
  "status": "INACTIVE",
  "updatedAt": "2026-06-12T10:30:00"
}

Dari sini, programmer, tester, dan analyst punya gambaran yang sama tentang bagaimana fitur bekerja.

3. REST APIs: Pola Umum untuk Mengelola Resource

REST API adalah salah satu gaya desain API yang sangat populer. Konsep utamanya adalah memandang data sebagai resource.

Contoh resource:

  • Customer
  • Invoice
  • Payment
  • Product
  • Order
  • User

Biasanya REST API menggunakan HTTP method seperti:

GET     /api/customers
GET     /api/customers/{id}
POST    /api/customers
PUT     /api/customers/{id}
PATCH   /api/customers/{id}
DELETE  /api/customers/{id}

Secara umum:

  • GET digunakan untuk mengambil data.
  • POST digunakan untuk membuat data baru atau menjalankan aksi tertentu.
  • PUT digunakan untuk mengganti data secara penuh.
  • PATCH digunakan untuk mengubah sebagian data.
  • DELETE digunakan untuk menghapus data.

Namun dalam aplikasi enterprise, tidak semua aksi cocok dianggap CRUD biasa.

Contohnya approval invoice:

POST /api/invoices/{invoiceId}/approve

Secara teknis ini mungkin mengubah status invoice. Tetapi dari sisi bisnis, ini bukan sekadar update field. Ada business rule, validasi role, audit trail, dan mungkin integrasi ke modul lain.

Inilah kenapa REST API tetap perlu dipahami bersama konteks bisnisnya. Jangan sampai semua hal dipaksakan menjadi endpoint CRUD sederhana, padahal proses bisnisnya jauh lebih kompleks.

4. Databases: Tempat Data Hidup dan Menjadi Sumber Kebenaran

Database adalah tempat aplikasi menyimpan data. Dalam project nyata, database bukan sekadar tempat menyimpan tabel. Database sering menjadi sumber kebenaran utama untuk proses bisnis.

Contohnya dalam sistem billing:

  • Customer disimpan di database.
  • Invoice disimpan di database.
  • Payment disimpan di database.
  • Status approval disimpan di database.
  • Audit log disimpan di database.

Dari sisi System Analyst, desain database sangat berkaitan dengan pertanyaan bisnis:

  • Data apa saja yang perlu disimpan?
  • Apakah data ini master data atau transaction data?
  • Apakah data boleh diubah?
  • Apakah perubahan data perlu disimpan historinya?
  • Siapa yang boleh mengakses data?
  • Apakah data ini akan dipakai untuk laporan?

Misalnya ada requirement:

“User bisa melihat riwayat perubahan status invoice.”

Ini berarti tidak cukup hanya menyimpan status terakhir di tabel invoice. Kita mungkin perlu tabel history, misalnya:

T_INVOICE_STATUS_HISTORY

Isinya bisa mencatat:

  • invoice_id
  • status_sebelumnya
  • status_baru
  • changed_by
  • changed_at
  • reason

Tanpa desain database yang tepat, fitur yang terlihat sederhana bisa sulit dikembangkan di kemudian hari.

5. SQL vs NoSQL: Pilih Berdasarkan Kebutuhan, Bukan Tren

SQL dan NoSQL sering dibandingkan seolah-olah salah satunya pasti lebih baik. Padahal, keduanya punya konteks penggunaan masing-masing.

SQL database seperti PostgreSQL, MySQL, Oracle, dan SQL Server cocok untuk data yang terstruktur dan memiliki relasi yang jelas.

Contohnya:

  • Customer memiliki banyak invoice.
  • Invoice memiliki banyak invoice detail.
  • Payment mengacu ke invoice.
  • User memiliki role.
  • Role memiliki permission.

SQL cocok saat kita butuh transaksi yang kuat, relasi data yang jelas, dan query yang kompleks.

Contoh data relasional:

CUSTOMER
- customer_id
- customer_name

INVOICE
- invoice_id
- customer_id
- invoice_date
- total_amount

Sementara itu, NoSQL database seperti MongoDB, Redis, Cassandra, atau DynamoDB biasanya cocok untuk kebutuhan yang lebih fleksibel, skala besar tertentu, atau pola akses data yang spesifik.

Contoh penggunaan NoSQL:

  • Menyimpan log aktivitas.
  • Menyimpan data semi-terstruktur.
  • Menyimpan cache.
  • Menyimpan event.
  • Menyimpan dokumen dengan struktur yang sering berubah.

Sebagai contoh, data preferensi user mungkin lebih fleksibel jika disimpan dalam bentuk dokumen:

{
  "userId": 1001,
  "preferences": {
    "theme": "dark",
    "language": "id",
    "notification": {
      "email": true,
      "sms": false
    }
  }
}

Namun ada hal yang perlu hati-hati. NoSQL bukan berarti tidak perlu desain. Tetap perlu memikirkan struktur data, indeks, pola query, konsistensi, dan kebutuhan reporting.

Dari sisi System Analyst, pertanyaan yang lebih penting bukan “pakai SQL atau NoSQL?”, tetapi:

“Data ini bentuknya seperti apa, berubah seberapa sering, relasinya kuat atau tidak, dan akan dibaca dengan pola seperti apa?”

6. Authentication vs Authorization: Login dan Hak Akses Itu Berbeda

Dua istilah ini sering muncul bersama, tetapi artinya berbeda.

Authentication adalah proses membuktikan siapa user tersebut.

Contoh:

  • User memasukkan email dan password.
  • Sistem memverifikasi credential.
  • Sistem menyatakan bahwa user tersebut valid.

Sederhananya:

Authentication menjawab pertanyaan: “Kamu siapa?”

Sedangkan authorization adalah proses menentukan apa saja yang boleh dilakukan oleh user tersebut.

Contoh:

  • User A boleh melihat invoice.
  • User B boleh membuat invoice.
  • User C boleh approve invoice.
  • User D hanya boleh melihat report.

Sederhananya:

Authorization menjawab pertanyaan: “Kamu boleh melakukan apa?”

Contoh requirement:

“Hanya supervisor yang boleh approve transaksi di atas Rp10.000.000.”

Requirement ini bukan hanya soal login. User memang harus login terlebih dahulu, tetapi setelah itu sistem juga harus mengecek apakah user memiliki role supervisor dan apakah nominal transaksi melewati batas tertentu.

Dalam desain sistem, authentication biasanya dibahas bersama fitur login. Authorization biasanya muncul saat membahas role, permission, workflow, approval, dan access control.

Hal yang perlu diwaspadai: jangan hanya menyembunyikan tombol di frontend.

Misalnya tombol Approve disembunyikan dari user biasa. Itu bagus untuk user experience, tetapi tidak cukup untuk keamanan. Backend tetap harus melakukan validasi authorization, karena request API bisa saja dikirim langsung tanpa melalui tombol di UI.

7. Session-based vs Token-based Authentication

Setelah user berhasil login, sistem perlu “mengingat” bahwa user tersebut sudah terautentikasi. Ada dua pendekatan umum: session-based dan token-based authentication.

Session-based Authentication

Pada pendekatan session-based, server menyimpan data session. Setelah login berhasil, server membuat session dan mengirim session ID ke client, biasanya melalui cookie.

Alurnya kira-kira seperti ini:

  1. User login.
  2. Server memvalidasi username dan password.
  3. Server membuat session.
  4. Browser menyimpan session ID di cookie.
  5. Setiap request berikutnya membawa cookie tersebut.
  6. Server mengecek session di storage.

Pendekatan ini banyak digunakan pada aplikasi web tradisional.

Kelebihannya:

  • Cocok untuk aplikasi web yang server-rendered.
  • Session bisa dicabut dari server.
  • Kontrol ada di sisi server.

Hal yang perlu diperhatikan:

  • Server perlu menyimpan session.
  • Jika sistem punya banyak server, session perlu dikelola dengan baik.
  • Perlu proteksi terhadap serangan seperti CSRF.

Token-based Authentication

Pada token-based authentication, server memberikan token setelah login berhasil. Client menyimpan token tersebut, lalu mengirimkannya pada request berikutnya.

Biasanya token dikirim melalui header:

Authorization: Bearer <token>

Alurnya kira-kira seperti ini:

  1. User login.
  2. Server memvalidasi credential.
  3. Server mengembalikan token.
  4. Client menyimpan token.
  5. Client mengirim token pada setiap request.
  6. Server memvalidasi token.

Pendekatan ini sering dipakai pada aplikasi modern, terutama yang memiliki frontend terpisah dari backend, aplikasi mobile, atau microservices.

Kelebihannya:

  • Cocok untuk API.
  • Cocok untuk aplikasi mobile.
  • Lebih mudah digunakan antar service jika dirancang dengan benar.
  • Server tidak selalu perlu menyimpan session.

Hal yang perlu diperhatikan:

  • Token harus dijaga dengan aman.
  • Expiration token perlu diatur.
  • Refresh token perlu didesain hati-hati.
  • Token yang bocor bisa disalahgunakan selama masih valid.

Tidak ada pendekatan yang selalu paling benar. Pilihannya tergantung arsitektur aplikasi, kebutuhan keamanan, jenis client, dan cara sistem akan dikembangkan.

8. JWT: Token yang Membawa Informasi

JWT adalah singkatan dari JSON Web Token. JWT sering digunakan dalam token-based authentication.

Secara sederhana, JWT adalah token yang berisi informasi dalam format tertentu dan ditandatangani secara digital.

JWT biasanya terdiri dari tiga bagian:

header.payload.signature

Contoh isi payload JWT bisa seperti ini:

{
  "sub": "1001",
  "name": "Budi Santoso",
  "role": "ADMIN",
  "iat": 1718179200,
  "exp": 1718182800
}

Beberapa field yang sering muncul:

  • sub: subject, biasanya ID user.
  • iat: issued at, waktu token dibuat.
  • exp: expiration time, waktu token kedaluwarsa.
  • role: role user, jika memang disimpan di token.

JWT membantu server memverifikasi request tanpa harus selalu mencari session di database. Namun JWT juga perlu digunakan dengan hati-hati.

Beberapa catatan penting:

Pertama, JWT bukan tempat menyimpan data rahasia. Payload JWT bisa dibaca jika token berhasil didapatkan oleh pihak lain. Karena itu, jangan menyimpan password, nomor kartu kredit, atau informasi sensitif di dalam payload JWT.

Kedua, JWT perlu memiliki masa berlaku. Token tanpa expiration berisiko tinggi jika bocor.

Ketiga, perubahan hak akses user perlu dipikirkan. Misalnya role user dicabut, tetapi JWT lama masih menyimpan role lama sampai token tersebut expired. Ini perlu didesain dengan strategi yang tepat, misalnya token expiration pendek, refresh token, atau token blacklist jika diperlukan.

Keempat, validasi authorization tetap harus dilakukan di backend. Jangan hanya percaya bahwa karena token berisi role tertentu, semua aksi langsung boleh dilakukan tanpa pengecekan rule yang sesuai.

9. Contoh Sederhana: Fitur Login dan Melihat Invoice

Agar lebih mudah, mari kita gabungkan semua konsep tadi dalam satu contoh.

Requirement:

“User bisa login dan melihat daftar invoice miliknya.”

Dari requirement sederhana ini, kita bisa melihat beberapa bagian sistem.

Client

Client menyediakan halaman login dan halaman daftar invoice.

User mengisi email dan password, lalu menekan tombol login.

API

Frontend mengirim request:

POST /api/auth/login

Dengan body:

{
  "email": "user@example.com",
  "password": "password"
}

Jika sukses, server mengembalikan token:

{
  "accessToken": "eyJhbGciOiJIUzI1NiIsInR5cCI..."
}

Lalu saat user membuka daftar invoice, frontend mengirim request:

GET /api/invoices
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI...

Server

Server melakukan beberapa hal:

  1. Memvalidasi token.
  2. Mengambil user ID dari token.
  3. Mengecek apakah user boleh melihat invoice.
  4. Mengambil data invoice dari database.
  5. Mengembalikan response ke client.

Database

Database menyimpan data user, customer, invoice, dan relasi antar data.

Misalnya:

USERS
CUSTOMERS
INVOICES
USER_CUSTOMER_ACCESS

Jika user hanya boleh melihat invoice miliknya, maka query backend harus memastikan data yang dikembalikan memang sesuai hak akses user tersebut.

Jadi, fitur “lihat invoice” bukan hanya soal menampilkan tabel. Ada authentication, authorization, API design, database query, dan security rule di belakangnya.

10. Kesalahan yang Sering Terjadi Saat Memahami Fondasi Web dan API

Beberapa kesalahan ini cukup umum terjadi, terutama saat tim terlalu cepat masuk ke coding tanpa menyamakan pemahaman desain.

Menganggap API hanya sebagai URL

API bukan hanya URL. API adalah kontrak antara client dan server. Di dalamnya ada request, response, validasi, error handling, security, dan business rule.

Menyamakan authentication dan authorization

User yang berhasil login belum tentu boleh melakukan semua aksi. Login hanya membuktikan identitas. Hak akses tetap perlu dicek.

Menyimpan terlalu banyak data di JWT

JWT sebaiknya hanya menyimpan data yang benar-benar diperlukan. Semakin banyak data di token, semakin besar risiko dan semakin sulit mengelola perubahan.

Memilih database karena tren

Database harus dipilih berdasarkan kebutuhan data, pola akses, transaksi, reporting, dan skalabilitas. Bukan hanya karena teknologi tersebut sedang populer.

Hanya mengamankan frontend

Menyembunyikan tombol di UI itu baik, tetapi tidak cukup. Backend tetap harus menjadi penjaga utama untuk validasi akses dan business rule.

11. Cara System Analyst Membaca Requirement Web dan API

Saat menerima requirement, System Analyst bisa menggunakan pertanyaan sederhana berikut.

Untuk sisi client:

  • Halaman apa yang dibutuhkan?
  • User melakukan aksi apa?
  • Data apa yang perlu ditampilkan?
  • Feedback apa yang muncul saat sukses atau gagal?

Untuk sisi API:

  • Endpoint apa yang diperlukan?
  • Request body seperti apa?
  • Response sukses seperti apa?
  • Error case apa saja?
  • Apakah API ini untuk create, read, update, delete, atau business action?

Untuk sisi database:

  • Data apa yang perlu disimpan?
  • Apakah perlu history?
  • Apakah perlu audit log?
  • Apakah datanya relasional?
  • Apakah data ini akan dipakai untuk laporan?

Untuk sisi security:

  • Siapa yang boleh login?
  • Siapa yang boleh melihat data?
  • Siapa yang boleh mengubah data?
  • Siapa yang boleh approve?
  • Apakah validasi akses dilakukan di backend?

Dengan pertanyaan-pertanyaan ini, requirement yang awalnya masih umum bisa diubah menjadi desain yang lebih jelas dan bisa dikerjakan oleh tim development.

Penutup

Fondasi web dan API bukan hanya materi teknis untuk backend developer. Konsep ini juga penting untuk frontend developer, mobile developer, QA, System Analyst, Product Owner, dan siapa pun yang terlibat dalam pengembangan aplikasi.

Dengan memahami client-server architecture, API design, REST API, database, SQL vs NoSQL, authentication, authorization, session, token, dan JWT, kita bisa membaca requirement dengan lebih matang.

Kita tidak hanya bertanya:

“Tombolnya ada di mana?”

Tetapi juga mulai bertanya:

“Data mengalir ke mana, rule-nya dijalankan di mana, siapa yang boleh akses, dan bagaimana sistem memastikan semuanya aman?”

Pada akhirnya, aplikasi yang baik bukan hanya aplikasi yang tampilannya jalan. Aplikasi yang baik juga punya alur data yang jelas, API yang rapi, database yang masuk akal, dan keamanan yang dipikirkan sejak awal.

Comments

You May Also Enjoy