Pertanyaan dan Jawaban Wawancara REST API (Panduan 2026)

REST API menggerakkan sebagian besar integrasi di internet. Baik Anda melamar peran backend, posisi full stack, atau pekerjaan rekayasa perangkat lunak, Anda kemungkinan akan menghadapi pertanyaan tentang desain REST API, metode HTTP, dan pola autentikasi.

Dalam panduan ini, saya akan mengajak Anda menelusuri pertanyaan-pertanyaan yang benar-benar diajukan oleh pewawancara. Saya mengelompokkannya berdasarkan tingkat kesulitan dan jenis peran, sehingga Anda bisa fokus pada hal yang paling relevan untuk posisi target Anda. Setiap jawaban mencakup contoh praktis dan, jika relevan, cuplikan kode yang dapat Anda adaptasi.

Satu hal yang perlu diingat: pewawancara jauh lebih sering menguji dasar-dasar daripada topik tingkat lanjut. Jika Anda menguasai hal-hal mendasar (metode HTTP, kode status, stateless), Anda akan menghadapi sebagian besar wawancara REST API dengan percaya diri. Pola arsitektur yang canggih menyusul kemudian.

Pertanyaan Wawancara REST API Dasar

Pertanyaan-pertanyaan ini menguji pengetahuan fundamental Anda. Harapkan muncul di hampir setiap wawancara, terlepas dari tingkat senioritas.

1. Apa itu REST dan apa saja batasannya?

REST adalah singkatan dari Representational State Transfer. Ini adalah gaya arsitektur untuk merancang aplikasi jaringan, didefinisikan oleh Roy Fielding dalam disertasi doktoralnya tahun 2000.

REST memiliki enam batasan:

1. Client-Server: Pemisahan tanggung jawab antara antarmuka pengguna dan penyimpanan data
2. Stateless: Setiap permintaan berisi semua informasi yang diperlukan untuk menyelesaikannya
3. Cacheable: Respons harus menunjukkan apakah dapat di-cache
4. Layered System: Komponen tidak dapat melihat melampaui lapisan terdekatnya
5. Uniform Interface: Cara baku untuk berinteraksi dengan sumber daya
6. Code-on-Demand (opsional): Server dapat mengirimkan kode yang dapat dieksekusi ke klien

2. Apa perbedaan antara REST dan SOAP?

REST adalah gaya arsitektur; SOAP adalah protokol. REST biasanya menggunakan JSON di atas HTTP dan memanfaatkan metode HTTP standar. SOAP menggunakan XML secara eksklusif dan mendefinisikan format pesan sendiri dengan amplop dan header.

SOAP masih masuk akal untuk sistem enterprise yang memerlukan kontrak formal (WSDL) atau keamanan tingkat pesan (WS-Security).

3. Apa itu metode HTTP dan kapan Anda menggunakan masing-masing?

Metode HTTP mendefinisikan aksi yang akan dilakukan pada suatu sumber daya.

4. Apa perbedaan antara PUT dan POST?

POST membuat sumber daya baru di mana server menentukan URI. PUT menggantikan sumber daya pada URI spesifik yang ditentukan klien.

POST /users          → Server creates user, returns /users/123
PUT /users/123       → Client specifies URI, replaces entire resource

Jika Anda melakukan PUT ke URI yang belum ada, server mungkin akan membuatnya. Jika Anda melakukan PUT ke URI yang sudah ada, Anda mengganti seluruh sumber daya.

5. Apa perbedaan antara PUT dan PATCH?

PUT menggantikan seluruh sumber daya. PATCH menerapkan modifikasi parsial.

# PUT replaces everything
PUT /users/123
{"name": "Khalid", "email": "khalid@example.com", "role": "admin"}

# PATCH updates only specified fields
PATCH /users/123
{"role": "admin"}

6. Apa arti "stateless" dalam REST?

Stateless berarti setiap permintaan harus memuat semua informasi yang dibutuhkan server untuk memprosesnya. Server tidak menyimpan konteks klien di antara permintaan.

Ini berarti tidak ada sesi sisi server. Jika pengguna diautentikasi, klien harus mengirim kredensial (biasanya token) pada setiap permintaan.

7. Apa yang membuat sebuah API bersifat RESTful?

Sebuah API benar-benar RESTful ketika memenuhi semua batasan REST, termasuk HATEOAS (Hypermedia as the Engine of Application State). Dalam praktiknya, sebagian besar API yang menyebut dirinya "REST" sebenarnya "mirip REST" atau berada di Level 2 pada Richardson Maturity Model. Dan jujur saja, itu sudah cukup untuk sebagian besar kasus penggunaan.

Tingkat Richardson Maturity Model untuk REST API. Gambar oleh Penulis.

8. Apa saja kode status HTTP dasar yang perlu Anda ketahui?

Anda sebaiknya memahami setidaknya tujuh kode status esensial ini yang mencakup mayoritas skenario API:

9. Apa perbedaan antara resource dan endpoint?

Resource adalah entitas data (pengguna, pesanan, produk). Endpoint adalah path URL yang menyediakan akses ke resource tersebut.

Resource: User
Endpoints: GET /users, GET /users/123, POST /users

10. Apa praktik terbaik untuk desain URI?

Gunakan kata benda, bukan kata kerja. Gunakan huruf kecil pada URI dengan tanda hubung untuk nama multi-kata. Gunakan kata benda jamak untuk koleksi.

Good:  /users, /users/123, /order-items
Bad:   /getUsers, /Users, /order_items

Hindari penurunan tingkat yang terlalu dalam. Alih-alih /users/123/posts/456/comments/789, pertimbangkan /comments/789 atau /comments?post_id=456.

11. Apa itu idempoten dan metode HTTP mana yang idempoten?

Sebuah operasi bersifat idempoten jika menjalankannya berkali-kali menghasilkan hasil yang sama seperti menjalankannya sekali.

PATCH yang mengatur sebuah nilai bersifat idempoten; PATCH yang menambah penghitung tidak.

12. Apa perbedaan antara metode yang aman dan idempoten?

Metode aman tidak memodifikasi sumber daya (GET, HEAD, OPTIONS). Metode idempoten dapat dipanggil berkali-kali dengan efek yang sama (GET, PUT, DELETE).

Semua metode aman adalah idempoten, tetapi tidak semua metode idempoten adalah aman. DELETE bersifat idempoten namun tidak aman karena memodifikasi state.

13. Kapan Anda harus menggunakan parameter kueri versus parameter path?

Parameter path mengidentifikasi resource tertentu. Parameter kueri memfilter, mengurutkan, atau melakukan paginasi pada koleksi.

Path:   /users/123              (specific user)
Query:  /users?status=active    (filtered collection)
        /users?sort=name&limit=10

14. Apa itu content negotiation?

Content negotiation memungkinkan klien meminta representasi berbeda dari suatu resource. Klien mengirim header Accept, dan server merespons dengan format yang sesuai.

Accept: application/json    → Server returns JSON
Accept: application/xml     → Server returns XML

15. Apa tujuan metode OPTIONS?

OPTIONS mengembalikan metode HTTP yang didukung server untuk URL tertentu. Browser menggunakannya untuk permintaan preflight CORS guna memeriksa apakah permintaan lintas origin diizinkan.

Pertanyaan Wawancara REST API Menengah

Pertanyaan-pertanyaan ini menguji penerapan praktis dan pengambilan keputusan. Harapkan untuk posisi level menengah.

16. Apa perbedaan antara 401 dan 403?

Ini adalah pasangan kode status yang paling sering membingungkan. Saya pernah melihat engineer senior tertukar saat code review.

401 Unauthorized

Berarti tidak diautentikasi. Server tidak tahu siapa Anda. Respons Anda harus meminta pengguna untuk masuk.

403 Forbidden

Berarti tidak diotorisasi. Server tahu siapa Anda tetapi Anda tidak memiliki izin. Melakukan autentikasi ulang tidak akan membantu.

Diagram alur keputusan kesalahan autentikasi versus otorisasi. Gambar oleh Penulis.

17. Apa perbedaan antara 400 dan 422?

Berikut contoh yang menggambarkan perbedaannya:

400 Bad Request

Ini menunjukkan sintaks tidak valid. Server tidak dapat mengurai permintaan (struktur JSON tidak valid, header wajib hilang).

422 Unprocessable Entity

Ini menunjukkan sintaks valid tetapi ada kesalahan semantik. JSON valid, tetapi data gagal validasi (format email tidak valid, kata sandi terlalu pendek).

# 400: Cannot parse
{"name": "Khalid",}  # Trailing comma breaks JSON

# 422: Valid JSON, invalid data
{"email": "not-an-email"}  # Fails validation

18. Kapan Anda harus menggunakan 409 Conflict?

Gunakan 409 ketika permintaan bertentangan dengan keadaan saat ini dari resource:

• Kegagalan optimistic locking (ketidakcocokan ETag)
• Pelanggaran batasan unik (nama pengguna duplikat)
• Transisi status tidak valid (membatalkan pesanan yang sudah dikirim)

19. Bagaimana Anda menerapkan paginasi?

Dua pendekatan utama:

Paginasi berbasis offset

Sederhana tetapi memiliki masalah kinerja dengan dataset besar.

GET /users?limit=20&offset=40

Paginasi berbasis kursor

Lebih skalabel dan menghindari "pergeseran halaman" saat data berubah.

GET /users?limit=20&cursor=eyJpZCI6MTIzfQ

Perusahaan seperti Stripe, GitHub, dan Slack menggunakan paginasi berbasis kursor untuk dataset besar.

20. Apa strategi versioning API yang umum?

Ada tiga pendekatan utama, masing-masing dengan trade-off berbeda:

Versioning URI

Ini yang paling umum. Eksplisit dan mudah di-debug.

GET /v1/users
GET /v2/users

Versioning header

URL lebih bersih tetapi lebih sulit diuji di browser.

GET /users
Accept-Version: v2

Versioning parameter kueri

Mudah ditambahkan tetapi membuat URL berantakan.

GET /users?version=2

21. Apa itu ETag dan bagaimana caching bekerja?

ETag adalah pengidentifikasi versi untuk sebuah resource. Server mengirimkannya dalam respons; klien mengirimkannya kembali dalam permintaan berikutnya untuk memeriksa apakah resource berubah.

# First request
GET /users/123
Response: ETag: "abc123"

# Subsequent request
GET /users/123
If-None-Match: "abc123"
Response: 304 Not Modified (if unchanged)

22. Metode autentikasi apa yang digunakan untuk REST API?

Empat metode autentikasi yang paling umum adalah API Key, Bearer Token, OAuth 2.0, dan JWT:

23. Apa itu JWT dan bagaimana cara kerjanya?

JWT (JSON Web Token) terdiri dari tiga bagian: Header, Payload, dan Signature. Pelajari lebih lanjut tentang bekerja dengan JSON di Python.

Header: {"alg": "RS256", "typ": "JWT"}
Payload: {"sub": "user123", "exp": 1704153600}
Signature: RSASHA256(base64(header) + "." + base64(payload), privateKey)

Server menandatangani token; klien mengirimkannya bersama permintaan. Server memvalidasi tanda tangan tanpa perlu lookup basis data.

24. Apa perbedaan antara RS256 dan HS256?

HS256 (simetris): Rahasia yang sama untuk menandatangani dan memverifikasi. Berisiko jika banyak layanan perlu memverifikasi token.

RS256 (asimetris): Kunci privat menandatangani, kunci publik memverifikasi. Direkomendasikan untuk sistem terdistribusi di mana banyak layanan memvalidasi token.

25. Apa itu HATEOAS?

HATEOAS (Hypermedia as the Engine of Application State) berarti respons menyertakan tautan ke aksi dan resource terkait.

{
  "id": 123,
  "name": "Khalid",
  "links": [
    {"rel": "self", "href": "/users/123"},
    {"rel": "orders", "href": "/users/123/orders"}
  ]
}

Dalam praktiknya, sebagian besar API tidak menerapkan HATEOAS sepenuhnya. Ketahui konsepnya tetapi jangan berharap untuk mengimplementasikannya di sebagian besar pekerjaan. Bahkan perusahaan teknologi besar jarang membangun API yang sepenuhnya patuh HATEOAS.

26. Bagaimana Anda menangani kesalahan secara konsisten?

Gunakan format RFC 7807 Problem Details untuk respons kesalahan yang konsisten:

{
  "type": "https://api.example.com/errors/validation",
  "title": "Validation Error",
  "status": 422,
  "detail": "Email format is invalid",
  "instance": "/users"
}

27. Apa itu rate limiting dan mengapa penting?

Rate limiting melindungi API Anda dari penyalahgunaan dan memastikan penggunaan yang adil. Respons yang umum:

HTTP/1.1 429 Too Many Requests
Retry-After: 3600
X-RateLimit-Limit: 1000
X-RateLimit-Remaining: 0

28. Bagaimana Anda merancang filtering dan sorting?

Gunakan parameter kueri dengan konvensi yang jelas:

# Filtering
GET /products?category=electronics&price[gte]=100&price[lte]=500

# Sorting (prefix - for descending)
GET /users?sort=-created_at,name

Pertanyaan Wawancara REST API Lanjutan

Pertanyaan-pertanyaan ini menguji pemikiran arsitektural. Harapkan untuk posisi senior.

29. Apa yang berubah antara OAuth 2.0 dan OAuth 2.1?

OAuth 2.1 mengonsolidasikan praktik terbaik keamanan:

Inti yang perlu diingat: gunakan Authorization Code flow dengan PKCE untuk semua jenis klien.

30. Bagaimana Anda menerapkan idempotensi untuk endpoint pembayaran?

Gunakan idempotency key agar permintaan POST aman untuk diulang:

async def handle_payment(request: Request, payment: PaymentCreate):
    idempotency_key = request.headers.get("Idempotency-Key")
    
    # Check if already processed
    cached = await redis.get(f"idem:{idempotency_key}")
    if cached:
        return JSONResponse(json.loads(cached))
    
    # Process payment
    result = await process_payment(payment)
    
    # Cache result (24-hour TTL)
    await redis.setex(f"idem:{idempotency_key}", 86400, json.dumps(result))
    return result

Klien menghasilkan UUID dan mengirimkannya bersama permintaan. Jika kunci yang sama datang lagi, kembalikan respons yang di-cache.

31. Bagaimana Anda merancang rate limiter terdistribusi?

Untuk sistem terdistribusi, Anda tidak dapat menggunakan penghitung dalam memori karena lalu lintas dibagi beban di banyak instance. Ini adalah jebakan umum yang sering menyesatkan kandidat.

Arsitektur:

1. Gunakan Redis untuk penyimpanan penghitung terpusat
2. Implementasikan algoritma Token Bucket untuk toleransi lonjakan
3. Gunakan operasi atomik (skrip Lua) untuk mencegah race condition

# Pseudocode for Token Bucket
tokens = redis.get(user_id) or max_tokens
if tokens > 0:
    redis.decr(user_id)
    process_request()
else:
    return 429

32. Kapan Anda memilih gRPC daripada REST?

Pilih gRPC untuk:

• Komunikasi antarmikrolayanan internal (peningkatan throughput 5-10x)
• Kebutuhan streaming real-time
• Mobile-ke-backend dengan keterbatasan bandwidth
• Lingkungan poliglot yang memerlukan kontrak ketat

Pilih REST untuk:

• API publik dengan konsumen beragam
• Aplikasi web (dukungan browser universal)
• Operasi CRUD sederhana
• Tim yang tidak terbiasa dengan Protocol Buffers

33. Bagaimana Anda menangani operasi yang berjalan lama?

Gunakan pola permintaan asinkron:

1. Klien mengirim permintaan

2. Server mengembalikan 202 Accepted dengan URL status

3. Klien melakukan polling ke URL status hingga selesai

POST /reports
Response: 202 Accepted
Location: /reports/abc123/status

GET /reports/abc123/status
Response: {"status": "processing", "progress": 45}

GET /reports/abc123/status
Response: {"status": "completed", "result_url": "/reports/abc123"}

34. Apa itu pola Saga?

Saga menangani transaksi terdistribusi di seluruh mikrolayanan tanpa penguncian. Setiap layanan menjalankan transaksi lokal dan memublikasikan event. Jika sebuah langkah gagal, transaksi kompensasi membatalkan langkah sebelumnya.

Order Created → Payment Processed → Inventory Reserved → Order Confirmed
                     ↓ (failure)
              Release Payment → Cancel Order

35. Apa kerentanan keamanan JWT yang umum?

Kebingungan algoritme Penyerang mengubah RS256 menjadi HS256 dan menandatangani dengan kunci publik. Perbaikan: selalu whitelist algoritme.

# Vulnerable
jwt.decode(token, key)

# Secure
jwt.decode(token, key, algorithms=["RS256"])

Algoritme "none": Penyerang menghapus tanda tangan sepenuhnya. Perbaikan: tolak algoritme "none".

Pertanyaan REST API untuk Pengembang Backend

36. Apa itu masalah kueri N+1?

Masalah N+1 terjadi ketika Anda mengambil N record dan kemudian menjalankan kueri terpisah untuk setiap relasi record tersebut.

# N+1 Problem: 101 queries for 100 users
users = User.query.all()  # 1 query
for user in users:
    print(user.posts)     # 100 queries

Solusi:

Django: Gunakan select_related() untuk foreign key, prefetch_related() untuk many-to-many.

# 2 queries instead of 101
users = User.objects.prefetch_related('posts').all()

SQLAlchemy: Gunakan joinedload() atau selectinload().

37. Bagaimana Anda mengonfigurasi connection pooling?

Connection pooling menggunakan kembali koneksi basis data alih-alih membuat yang baru untuk setiap permintaan.

# SQLAlchemy
engine = create_engine(
    "postgresql://user:pass@host/db",
    pool_size=5,           # Permanent connections
    max_overflow=10,       # Temporary overflow
    pool_timeout=30,       # Wait timeout
    pool_pre_ping=True     # Validate before use
)

38. Strategi caching apa yang Anda ketahui?

Ada tiga strategi caching utama, masing-masing dioptimalkan untuk pola akses berbeda:

39. Bagaimana Anda menerapkan verifikasi tanda tangan webhook?

import hmac
import hashlib

def verify_webhook(payload: bytes, signature: str, secret: str) -> bool:
    expected = 'sha256=' + hmac.new(
        secret.encode(),
        payload,
        hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, signature)

40. Metrik apa yang menunjukkan kesehatan API?

Anda harus memantau empat metrik kunci ini untuk menilai kesehatan API Anda:

Pertanyaan REST API untuk Pengembang Full Stack

41. Kapan browser mengirim permintaan preflight CORS?

Browser mengirim OPTIONS preflight untuk:

• Metode selain GET, HEAD, POST
• Header kustom (Authorization, X-API-Key)
• Content-Type selain form-urlencoded, multipart/form-data, text/plain

42. Bagaimana Anda mengonfigurasi CORS secara aman?

// Express.js
app.use(cors({
  origin: ['https://yourdomain.com'],  // Never use * with credentials
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
  allowedHeaders: ['Content-Type', 'Authorization']
}));

Jangan pernah gunakan wildcard (*) dengan kredensial. Jangan pernah mengizinkan origin null.

43. Di mana Anda harus menyimpan token di sisi klien?

Penyimpanan token melibatkan trade-off keamanan antara kerentanan XSS dan CSRF"

Praktik terbaik: Simpan refresh token di cookie HttpOnly dengan SameSite=Strict. Simpan access token di memori.

44. Kapan Anda harus menggunakan WebSocket versus SSE?

Pilihan bergantung pada apakah Anda memerlukan komunikasi dua arah dan bagaimana Anda ingin menangani penyambungan ulang:

Gunakan SSE untuk notifikasi, umpan langsung, ticker saham. Gunakan WebSocket untuk chat, gim multipemain, pengeditan kolaboratif.

45. Bagaimana Anda menangani pengunggahan file?

Untuk file besar, gunakan unggah bertahap (chunked) dengan pelacakan progres:

async function chunkedUpload(file, chunkSize = 5 * 1024 * 1024) {
  const totalChunks = Math.ceil(file.size / chunkSize);
  
  for (let i = 0; i < totalChunks; i++) {
    const chunk = file.slice(i * chunkSize, (i + 1) * chunkSize);
    await uploadChunk(uploadId, i, chunk);
  }
}

Pertanyaan REST API Berbasis Skenario

46. Rancang REST API untuk sistem pemesanan hotel

Resource:

• /hotels - Daftar dan cari hotel

• /hotels/{id}/rooms - Kamar yang tersedia

• /bookings - Membuat dan mengelola pemesanan

• /guests/{id} - Profil tamu

Keputusan kunci:

• Gunakan paginasi berbasis kursor untuk pencarian hotel
• Terapkan optimistic locking untuk ketersediaan kamar
• Kembalikan 409 Conflict untuk upaya double-booking
• Gunakan idempotency key untuk pemrosesan pembayaran

47. Bagaimana Anda mengimplementasikan soft delete?

Tambahkan timestamp deleted_at alih-alih menghapus record:

@app.delete("/users/{user_id}")
def delete_user(user_id: int):
    user = db.get(user_id)
    user.deleted_at = datetime.utcnow()
    db.commit()
    return Response(status_code=204)

@app.get("/users")
def list_users(include_deleted: bool = False):
    query = User.query
    if not include_deleted:
        query = query.filter(User.deleted_at.is_(None))
    return query.all()

48. Bagaimana Anda bermigrasi dari v1 ke v2 tanpa merusak klien?

Gunakan pola Strangler Fig:

1. Deploy v2 berdampingan dengan v1
2. Arahkan fitur baru ke v2
3. Secara bertahap migrasikan endpoint yang ada
4. Komunikasikan deprecasi melalui header Sunset
5. Hapus v1 setelah periode migrasi

49. Bagaimana Anda merancang API pencarian dengan penyaringan kompleks?

Untuk pencarian produk dengan banyak filter:

GET /products?q=laptop&category=electronics&price[gte]=500&price[lte]=2000&brand=apple,dell&in_stock=true&sort=-rating&limit=20&cursor=abc123

Keputusan desain:

• Gunakan Elasticsearch untuk pencarian full-text (basis data relasional kesulitan menangani pencocokan fuzzy)
• Terapkan faceted search untuk menampilkan opsi filter yang tersedia
• Kembalikan jumlah filter sehingga pengguna tahu berapa hasil untuk tiap filter
• Cache kombinasi pencarian populer

50. Bagaimana Anda menangani versioning API dalam arsitektur mikrolayanan?

Opsi:

1. Versioning di tingkat gateway: API gateway merutekan /v1/* ke layanan lama, /v2/* ke layanan baru

2. Versioning di tingkat layanan: Setiap layanan menangani negosiasi versinya sendiri

3. Kontrak yang didorong konsumen: Gunakan Pact atau alat serupa untuk memastikan kompatibilitas

Untuk sebagian besar tim, versioning di tingkat gateway memberikan pemisahan yang paling bersih.

51. Bagaimana Anda menerapkan rate limiting untuk tier pengguna yang berbeda?

Solusinya melibatkan penentuan limit khusus per tier dan memeriksanya menggunakan penghitung Redis:

RATE_LIMITS = {
    "free": {"requests": 100, "window": 3600},
    "pro": {"requests": 1000, "window": 3600},
    "enterprise": {"requests": 10000, "window": 3600}
}

async def rate_limit_middleware(request: Request):
    user = get_current_user(request)
    tier = user.subscription_tier
    limits = RATE_LIMITS[tier]
    
    key = f"rate:{user.id}:{current_hour()}"
    count = await redis.incr(key)
    
    if count == 1:
        await redis.expire(key, limits["window"])
    
    if count > limits["requests"]:
        raise HTTPException(
            status_code=429,
            headers={
                "X-RateLimit-Limit": str(limits["requests"]),
                "X-RateLimit-Remaining": "0",
                "Retry-After": str(seconds_until_reset())
            }
        )

Pertanyaan REST API Perilaku

52. Jelaskan REST kepada orang non-teknis

"Bayangkan REST API seperti pelayan di restoran. Anda (pelanggan) tidak bisa langsung masuk ke dapur. Sebagai gantinya, Anda memberi tahu pelayan apa yang Anda inginkan dari menu, dan mereka membawakannya. Menu itu seperti dokumentasi API, mencantumkan apa yang bisa Anda pesan. Pelayan mengikuti aturan tertentu: Anda meminta sesuatu (GET), Anda memesan sesuatu yang baru (POST), atau Anda mengembalikan sesuatu (DELETE). Jika dapur kehabisan sesuatu, pelayan memberi tahu Anda (404 Not Found) sehingga Anda tidak menunggu selamanya."

Analogi ini terbukti cukup efektif dalam rapat dengan pemangku kepentingan.

53. Jelaskan saat Anda mengoptimalkan sebuah API

Gunakan metode STAR:

• Situation: "API pencarian kami memiliki waktu respons 3 detik selama lalu lintas puncak"
• Task: "Saya perlu menurunkan latensi tanpa perubahan arsitektur besar"
• Action: "Saya menambahkan caching Redis untuk kueri sering, menerapkan paginasi berbasis kursor, dan menambahkan indeks basis data"
• Result: "Waktu respons turun menjadi 200ms, dan kami menangani 5x lebih banyak lalu lintas"

54. Bagaimana Anda mengomunikasikan breaking changes kepada konsumen API?

1. Umumkan lebih awal: Beri pemberitahuan setidaknya 6-12 bulan untuk perubahan besar

2. Gunakan header Sunset: Sunset: Sat, 31 Dec 2026 23:59:59 GMT

3. Sediakan panduan migrasi: Dokumentasikan dengan jelas apa yang berubah dan cara beradaptasi

4. Jalankan kedua versi: Pertahankan versi lama tetap berjalan selama transisi

5. Pantau penggunaan: Lacak klien mana yang masih menggunakan versi lama

55. Dokumentasi apa yang Anda buat untuk API?

Dokumentasi esensial mencakup:

• Spesifikasi OpenAPI/Swagger: Kontrak yang dapat dibaca mesin
• Panduan memulai: Panggilan API pertama dalam waktu kurang dari 5 menit
• Panduan autentikasi: Cara memperoleh dan menggunakan kredensial
• Referensi kesalahan: Semua kode kesalahan yang mungkin dan cara menanganinya
• Changelog: Perubahan pada setiap versi
• Dokumentasi rate limit: Batas per tier dan cara menangani 429

56. Kapan Anda TIDAK menggunakan REST?

REST tidak selalu pilihan yang tepat. Mengetahui kapan menggunakan alternatif menunjukkan kedewasaan arsitektural. Saya melihat tim memaksakan REST pada use case yang justru menimbulkan lebih banyak masalah daripada manfaat.

Referensi Cepat REST API

Gunakan bagian ini sebagai rujukan cepat saat Anda perlu memverifikasi properti metode HTTP, kode status, atau pola umum saat persiapan wawancara atau pengembangan nyata.

Perbandingan Metode HTTP

Tabel ini merangkum properti kunci setiap metode HTTP, membantu Anda memilih yang tepat untuk kasus penggunaan Anda.

Referensi Kode Status

Berikut kode status HTTP yang paling umum digunakan, diorganisasi berdasarkan kategori. Fokuslah memahami kapan menggunakannya daripada menghafal seluruh spesifikasi.

2xx Sukses

• 200 OK: GET, PUT, PATCH berhasil
• 201 Created: POST berhasil (sertakan header Location)
• 204 No Content: DELETE berhasil

4xx Kesalahan Klien

• 400 Bad Request: Sintaks tidak valid
• 401 Unauthorized: Perlu autentikasi
• 403 Forbidden: Diautentikasi tetapi tidak diotorisasi
• 404 Not Found: Resource tidak ada
• 409 Conflict: Konflik state
• 422 Unprocessable Entity: Kesalahan validasi
• 429 Too Many Requests: Terkena rate limit

5xx Kesalahan Server

• 500 Internal Server Error: Kegagalan server umum
• 502 Bad Gateway: Kesalahan server hulu
• 503 Service Unavailable: Sementara kelebihan beban

Kesalahan Umum yang Perlu Dihindari

Bahkan pengembang berpengalaman pun bisa terjebak. Waspadai jebakan umum berikut saat merancang atau mengimplementasikan REST API:

• Menggunakan kata kerja dalam URL (mis., /getUsers alih-alih /users)

• Mengembalikan 200 OK untuk kondisi error, yang merusak penanganan error di sisi klien

• Membingungkan 401 dan 403 (Autentikasi vs. Otorisasi)

• Menumpuk URL terlalu dalam lebih dari dua level

• Menyimpan token di localStorage (menimbulkan kerentanan XSS)

• Mengabaikan idempotensi untuk permintaan POST

• Mengembalikan pesan error generik tanpa detail yang dapat ditindaklanjuti

Kesimpulan

Saya menyadari bahwa menghafal definisi tidak akan menjamin Anda lulus setiap wawancara teknis. Kenyataannya adalah rekayasa di dunia nyata sering kali membutuhkan pelanggaran terhadap "aturan" ketat yang baru saja kita bahas, dan pewawancara lebih peduli pada penalaran Anda daripada kemampuan Anda mengutip spesifikasi RFC. Untuk peran yang sangat khusus, pengetahuan domain mendalam atau keahlian kerangka kerja tertentu mungkin tetap menjadi faktor penentu.

Namun menguasai dasar-dasar REST tetap penting meskipun Anda tidak menemui pertanyaan-pertanyaan yang persis sama. Ini menjadi cetak biru untuk memahami cara kerja web modern. Ketika Anda diminta merancang sistem baru atau men-debug gangguan produksi, memahami perbedaan antara 401 dan 403 (seperti yang saya jelaskan sebelumnya) memberi Anda kejelasan untuk memecahkan masalah lebih cepat. Anda akan menyadari mengapa standarisasi interaksi API Anda, bukan sekadar menulis kode yang berfungsi, adalah ciri khas engineer senior.

Jika Anda ingin menyelami lebih dalam pembangunan sistem-sistem ini, lihat Introduction to APIs in Python kami.