# Menangani Masalah Tipe Data Tidak Terduga dan Kompleksitas Struktur Model pada API

Dalam pengembangan API, salah satu tantangan utama adalah **menangani data yang tidak sesuai dengan ekspektasi** dan **beragam struktur data** terutama pada request dan response. Masalah ini bisa muncul dalam berbagai bahasa pemrograman dan framework, termasuk TypeScript, JavaScript, Go, Python, dan lainnya.

---

## 1\. Masalah Data dengan Tipe Tidak Sesuai

Misal Anda membuat fungsi sederhana seperti ini:

```typescript
function jumlah(a: number, b: number): number {
  return a + b;
}
```

Idealnya, `a` dan `b` harus bertipe `number`. Namun, jika API menerima `string`, misalnya `"5"` atau `"abc"`, dan langsung dieksekusi tanpa validasi, maka:

* Bisa terjadi **konversi implisit** yang menghasilkan hasil tak terduga (`"5" + "6" = "56"`).
    
* Bisa terjadi error runtime jika operasi tidak bisa dilakukan.
    

### Kenapa ini terjadi?

* Data yang datang dari request HTTP adalah **string** secara default.
    
* Tanpa validasi eksplisit, data langsung diproses.
    
* Di JavaScript/TypeScript, operator `+` antara string dan number akan melakukan **konkatenasi string**.
    

### Dampak buruknya:

* Data salah diolah, menghasilkan output yang tidak valid.
    
* API menjadi tidak dapat diandalkan.
    
* Sulit untuk debugging dan tracing kesalahan.
    

---

## 2\. Bagaimana Cara Menangani Masalah Tipe Data?

### a. Validasi input secara eksplisit

Gunakan **validasi tipe data** pada awal fungsi atau API endpoint sebelum diproses.

Contoh dengan TypeScript dan `typeof`:

```typescript
function jumlah(a: unknown, b: unknown): number {
  if (typeof a !== 'number' || typeof b !== 'number') {
    throw new Error('Parameter harus bertipe number');
  }
  return a + b;
}
```

Atau menggunakan library validasi seperti **Zod**, **Joi**, atau **Yup**:

```typescript
import { z } from 'zod';

const jumlahSchema = z.object({
  a: z.number(),
  b: z.number(),
});

function jumlah(data: unknown) {
  const parsed = jumlahSchema.parse(data); // validasi dan konversi otomatis
  return parsed.a + parsed.b;
}
```

### b. Parsing eksplisit dan sanitasi data

Jika data bisa berupa string angka, konversi terlebih dahulu:

```typescript
function jumlah(a: unknown, b: unknown): number {
  const numA = Number(a);
  const numB = Number(b);

  if (isNaN(numA) || isNaN(numB)) {
    throw new Error('Parameter harus berupa angka valid');
  }

  return numA + numB;
}
```

---

## 3\. Menangani API dengan Banyak Struktur Model (Variasi Response)

Saat Anda membuat GET API yang **mendapatkan data dengan banyak bentuk struktur model**, tantangannya adalah:

* Bagaimana cara menentukan tipe data yang valid?
    
* Bagaimana cara memvalidasi response?
    
* Bagaimana cara menyusun kode agar mudah dipelihara?
    

### Contoh kasus:

API bisa merespon dengan format data yang berbeda berdasarkan kondisi tertentu.

Misal:

```json
// Model A
{ "type": "A", "value": 123 }

// Model B
{ "type": "B", "name": "John", "age": 30 }
```

### Pendekatan penanganannya:

#### a. Gunakan **Discriminated Union Types** (di TypeScript)

Jika API response bisa berbeda bentuk tapi ada field discriminator (`type`):

```typescript
type ModelA = { type: 'A'; value: number };
type ModelB = { type: 'B'; name: string; age: number };

type ResponseModel = ModelA | ModelB;

function handleResponse(data: ResponseModel) {
  if (data.type === 'A') {
    // proses data model A
  } else if (data.type === 'B') {
    // proses data model B
  }
}
```

#### b. Gunakan **Validation Schema** sesuai struktur

Dengan Zod atau Joi, buat skema yang sesuai dengan setiap model:

```typescript
const modelASchema = z.object({
  type: z.literal('A'),
  value: z.number(),
});

const modelBSchema = z.object({
  type: z.literal('B'),
  name: z.string(),
  age: z.number(),
});

const responseSchema = z.union([modelASchema, modelBSchema]);

const parsedData = responseSchema.parse(apiResponse);
```

#### c. Modularisasi kode untuk setiap model

Pisahkan handler dan validator untuk setiap model agar kode lebih mudah dipelihara.

#### d. Dokumentasikan API dengan baik

Gunakan OpenAPI (Swagger) untuk mendefinisikan berbagai response secara jelas.

---

## 4\. Kesimpulan dan Best Practices

| **Masalah** | **Solusi** |
| --- | --- |
| Data input tidak sesuai tipe | Validasi input, parsing, gunakan schema |
| Operasi pada tipe tidak valid | Tangani error dan fallback |
| Banyak struktur model API | Gunakan discriminated union, schema union |
| Model kompleks | Modularisasi, dokumentasi, unit test |