JSON và Data Formats — API and Technical Fundamentals cho BA

Mở đầu — vì sao bài này quan trọng

Nếu bạn là một Business Analyst (BA) và mới chỉ nghe loáng thoáng về API trong bài trước, thì JSON chính là "ngôn ngữ" mà các API hiện đại dùng để nói chuyện với nhau. Cứ mỗi lần bạn mở app ngân hàng để xem số dư, đặt một cốc trà sữa trên ShopeeFood, hay đăng nhập Zalo, thì đằng sau màn hình có hàng chục gói dữ liệu JSON đang bay qua bay lại giữa điện thoại của bạn và máy chủ. JSON ở khắp mọi nơi.

Tại sao một BA — người không viết code — lại phải hiểu JSON? Vì trong công việc hằng ngày, bạn sẽ phải đọc tài liệu API, kiểm tra dữ liệu trả về có đúng yêu cầu nghiệp vụ không, mô tả cho lập trình viên biết "một đơn hàng gồm những trường thông tin gì", và phối hợp với QA để xác nhận hệ thống chạy đúng. Tất cả những việc đó đều xoay quanh việc đọc và hiểu cấu trúc dữ liệu. Một BA đọc thông thạo JSON sẽ giao tiếp với đội kỹ thuật nhanh hơn, viết tài liệu chính xác hơn, và phát hiện lỗi nghiệp vụ sớm hơn rất nhiều.

Bài này tập trung riêng vào JSON và các định dạng dữ liệu (data formats) ở mức nền tảng: JSON là gì, cú pháp ra sao, các kiểu dữ liệu cơ bản, và làm sao đọc một khối JSON cho đúng. Những chủ đề chuyên sâu hơn như nested phức tạp, array lồng nhau, JSON Schema, hay so sánh với XML sẽ được học kỹ ở các bài sau. Mục tiêu của bài này là giúp bạn "nhìn vào một khối JSON và không còn thấy sợ".

Khái niệm cốt lõi

JSON là gì?

JSON viết tắt của JavaScript Object Notation — tạm dịch là "ký pháp đối tượng JavaScript". Dù tên gọi xuất phát từ ngôn ngữ JavaScript, ngày nay JSON là định dạng độc lập, được mọi ngôn ngữ lập trình (Java, Python, PHP, C#...) đọc và viết được. Nó là định dạng phổ biến nhất để truyền dữ liệu qua API.

Bản chất JSON chỉ là văn bản thuần (plain text) được sắp xếp theo một bộ quy tắc nhất định. Điều tuyệt vời của JSON là nó vừa dễ cho máy đọc, vừa dễ cho con người đọc. Bạn có thể mở một file JSON bằng Notepad và vẫn hiểu được nội dung — khác hẳn với các định dạng nhị phân (binary) khó hiểu.

Cú pháp cơ bản

Hãy nhìn ví dụ đơn giản này về một người dùng:

{
  "user": {
    "id": 1,
    "name": "Nguyễn Văn An",
    "email": "an.nguyen@example.com",
    "isActive": true,
    "age": 28
  }
}

Có vài quy tắc bạn cần ghi nhớ:

Toàn bộ dữ liệu được bao trong cặp ngoặc nhọn { } — đây gọi là một object (đối tượng).
Dữ liệu được tổ chức theo cặp key-value (khóa-giá trị), ví dụ "name": "Nguyễn Văn An". Bên trái dấu hai chấm là key (tên trường), bên phải là value (giá trị).
Mỗi cặp key-value cách nhau bằng dấu phẩy ,. Lưu ý: cặp cuối cùng KHÔNG có dấu phẩy theo sau.
Key luôn luôn phải nằm trong dấu nháy kép " ". Đây là điểm khác biệt quan trọng so với JavaScript.

Các kiểu dữ liệu (data types) trong JSON

JSON hỗ trợ một số kiểu giá trị cơ bản. Việc phân biệt được chúng giúp BA viết đặc tả chính xác:

String (chuỗi văn bản): luôn nằm trong nháy kép. Ví dụ: "Nguyễn Văn An", "0901234567". Lưu ý số điện thoại thường được lưu dạng string để giữ số 0 đầu.
Number (số): không có nháy kép. Ví dụ: 28, 150000, 3.14. JSON không phân biệt số nguyên và số thực — đều là number.
Boolean (đúng/sai): chỉ có hai giá trị true hoặc false, viết thường, không nháy kép. Ví dụ: "isActive": true.
null (rỗng): biểu thị "không có giá trị" hoặc "chưa biết". Ví dụ: "phoneNumber": null. Khác hẳn với chuỗi rỗng "".
Object (đối tượng): một cụm key-value nằm trong { }, có thể lồng vào nhau.
Array (mảng): một danh sách các giá trị nằm trong ngoặc vuông [ ].

Object và Array — hai cấu trúc xương sống

Hai cấu trúc quan trọng nhất bạn phải nắm là object và array.

Object dùng khi bạn mô tả một thực thể có nhiều thuộc tính — ví dụ một khách hàng có tên, email, tuổi. Dấu hiệu nhận biết: cặp ngoặc nhọn { }.

Array dùng khi bạn có một danh sách nhiều phần tử cùng loại — ví dụ danh sách sản phẩm trong giỏ hàng. Dấu hiệu nhận biết: cặp ngoặc vuông [ ]. Các phần tử cách nhau bằng dấu phẩy:

{
  "order": {
    "orderId": "DH2026-0517",
    "customer": "Trần Thị Bích",
    "items": [
      { "product": "Trà sữa trân châu", "quantity": 2, "price": 35000 },
      { "product": "Bánh flan", "quantity": 1, "price": 15000 }
    ],
    "totalAmount": 85000,
    "isPaid": false
  }
}

Trong ví dụ trên, items là một array chứa hai object. Đây chính là kiểu cấu trúc "object lồng array, array lồng object" mà bạn sẽ gặp đi gặp lại trong đời làm BA. Nhìn thì rối, nhưng nếu bạn đọc theo lớp — từ ngoài vào trong — nó rất logic: đơn hàng (object) chứa một danh sách món (array), mỗi món lại là một object có tên, số lượng, giá.

Vì sao JSON "thắng" các định dạng khác?

Trước JSON, người ta hay dùng XML (sẽ học ở bài 13). JSON thắng thế vì nhẹ hơn, ít ký tự thừa hơn, và đọc nhanh hơn. Một dữ liệu mô tả bằng XML có thể dài gấp đôi JSON. Trong thời đại mọi thứ phải nhanh — đặc biệt trên mạng di động ở Việt Nam — sự gọn nhẹ này tiết kiệm băng thông và tăng tốc độ phản hồi đáng kể.

Tình huống thực tế

Tình huống 1: BA tại sàn TMĐT phát hiện sai sót định dạng giá

Chị Linh là BA tại một sàn thương mại điện tử ở TP.HCM. Đội kỹ thuật bàn giao API trả về thông tin sản phẩm, và phản hồi mẫu như sau:

{
  "productId": 8842,
  "name": "Áo thun nam cotton",
  "price": "299000",
  "inStock": true
}

Nhìn thoáng qua thì ổn, nhưng chị Linh để ý price đang là string ("299000" có nháy kép) chứ không phải number (299000). Chị đặt câu hỏi với dev: nếu giá là string thì khi app cần tính tổng tiền giỏ hàng hoặc áp mã giảm giá, hệ thống phải tự chuyển đổi (convert) — dễ phát sinh lỗi cộng nhầm kiểu "299000" + "50000" thành "29900050000". Dev xác nhận đúng là một thiếu sót và sửa lại thành number.

Bài học: Một BA hiểu phân biệt string và number có thể bắt lỗi nghiệp vụ ngay từ khâu review API, trước khi nó gây sự cố tính tiền sai cho khách hàng thật.

Tình huống 2: Tích hợp cổng thanh toán và trường null gây hiểu nhầm

Anh Phúc làm BA cho một startup fintech ở Hà Nội, đang tích hợp với một cổng thanh toán. Khi giao dịch đang chờ xử lý, API trả về:

{
  "transactionId": "TXN-99213",
  "status": "PENDING",
  "completedAt": null,
  "amount": 1200000
}

Đội QA báo "lỗi" vì trường completedAt (thời điểm hoàn tất) bị trống. Anh Phúc giải thích: null ở đây không phải lỗi — nó có chủ đích, mang ý nghĩa "giao dịch chưa hoàn tất nên chưa có thời điểm hoàn tất". Khi giao dịch thành công, trường này sẽ được điền giá trị thời gian thật. Anh ghi rõ điều này vào tài liệu đặc tả để QA và dev hiểu đúng quy ước.

Bài học: null là một giá trị có ý nghĩa nghiệp vụ, không phải dữ liệu hỏng. BA cần định nghĩa rõ "trường nào được phép null, và null nghĩa là gì" để cả team không hiểu nhầm.

Tình huống 3: Đọc array để xác nhận yêu cầu nghiệp vụ giao hàng

Chị Hương là BA tại một công ty logistics ở Đà Nẵng. Yêu cầu nghiệp vụ: một đơn giao hàng có thể đi qua nhiều trạm trung chuyển. Dev gửi mẫu dữ liệu:

{
  "shipmentCode": "GHN-557120",
  "checkpoints": [
    { "station": "Kho Đà Nẵng", "time": "2026-06-25T08:00:00", "status": "Đã lấy hàng" },
    { "station": "Trung chuyển Huế", "time": "2026-06-25T14:30:00", "status": "Đang vận chuyển" },
    { "station": "Kho Hà Nội", "time": "2026-06-26T09:15:00", "status": "Đang giao" }
  ]
}

Nhờ đọc được array checkpoints, chị Hương xác nhận hệ thống đáp ứng đúng yêu cầu "theo dõi đa trạm". Chị còn nhận ra cần bổ sung quy tắc: các phần tử trong array phải được sắp xếp theo thứ tự thời gian tăng dần, nếu không màn hình tracking của khách hàng sẽ hiển thị lộn xộn.

Bài học: Hiểu array giúp BA kiểm tra các yêu cầu dạng "danh sách/nhiều bản ghi" và phát hiện các quy tắc nghiệp vụ ẩn (như thứ tự sắp xếp) mà đặc tả ban đầu chưa nói tới.

Hướng dẫn từng bước

Đây là quy trình đọc một khối JSON bất kỳ, áp dụng được ngay cả khi bạn mới làm quen:

Xác định cấu trúc ngoài cùng. Nhìn ký tự đầu tiên: nếu là { thì đây là một object (một thực thể); nếu là [ thì đây là một array (một danh sách). Đây là bước định hướng quan trọng nhất.

Đọc các key ở tầng trên cùng. Lướt qua các tên trường ở lớp đầu để nắm "khối dữ liệu này nói về cái gì" — ví dụ thấy orderId, customer, items thì biết ngay đây là một đơn hàng.

Xác định kiểu của từng value. Với mỗi trường, hỏi: nó là string, number, boolean, null, object hay array? Có nháy kép là string; không nháy mà là số là number; true/false là boolean.

Đi sâu vào các cấu trúc lồng. Khi gặp value là { } hoặc [ ], hãy "đi vào trong" và lặp lại bước 2-3 cho lớp đó. Cứ bóc tách từng lớp như bóc củ hành.

Đối chiếu với yêu cầu nghiệp vụ. Kiểm tra: đủ trường chưa? Kiểu dữ liệu đúng chưa? Trường nào null có hợp lý không? Đây là lúc tư duy BA của bạn phát huy.

Dùng công cụ định dạng (formatter). Nếu JSON quá dài và bị dồn cục một dòng, hãy dán vào một công cụ format online (ví dụ jsonformatter.org) hoặc tính năng "Beautify" trong Postman để nó tự thụt lề cho dễ đọc.

Lỗi thường gặp & mẹo

Quên dấu phẩy hoặc thừa dấu phẩy cuối. Lỗi phổ biến nhất. JSON không cho phép dấu phẩy sau phần tử cuối cùng. Ví dụ sai: { "a": 1, "b": 2, } — dấu phẩy sau số 2 làm JSON hỏng.

Dùng nháy đơn thay vì nháy kép. JSON bắt buộc nháy kép ". Viết { 'name': 'An' } là sai chuẩn JSON, dù trông giống.

Quên nháy kép cho key. { name: "An" } là cú pháp JavaScript, không phải JSON. Key bắt buộc phải có nháy kép: { "name": "An" }.

Nhầm lẫn null, chuỗi rỗng và số 0. Ba thứ này hoàn toàn khác nhau về nghiệp vụ: null nghĩa là "không có/chưa biết", "" là "có nhưng rỗng", 0 là "giá trị bằng không". Một BA nhầm ba thứ này có thể viết sai đặc tả nghiêm trọng.

Để dấu nháy kép trong value số. "price": "100" (string) và "price": 100 (number) khác nhau. Như tình huống 1 đã thấy, điều này ảnh hưởng tới việc tính toán.

Mẹo dùng công cụ kiểm tra: Khi nghi ngờ một khối JSON có hợp lệ không, hãy dán vào một JSON validator (như jsonlint.com). Nó sẽ chỉ chính xác dòng nào sai. Đây là công cụ "cứu cánh" rất nhanh cho BA, không cần biết code.

Mẹo đặt tên trường: Khi đề xuất cấu trúc dữ liệu cho dev, hãy ưu tiên tên trường rõ nghĩa, nhất quán (ví dụ luôn dùng camelCase như customerName, hoặc luôn dùng snake_case như customer_name — chọn một và giữ nguyên). Tên nhất quán giúp toàn hệ thống dễ bảo trì.

Bài tập thực hành

Bài 1 — Đọc hiểu: Cho khối JSON sau, hãy trả lời: (a) cấu trúc ngoài cùng là object hay array? (b) trường tags thuộc kiểu gì? (c) discount có ý nghĩa nghiệp vụ gì?

{
  "courseId": "API-101",
  "title": "API Fundamentals cho BA",
  "price": 499000,
  "discount": null,
  "isPublished": true,
  "tags": ["api", "ba", "rest"]
}

Bài 2 — Tìm lỗi: Khối JSON dưới đây có ít nhất 3 lỗi cú pháp. Hãy tìm và sửa:

{
  'studentName': "Lê Minh",
  "score": "8.5",
  "passed": true,
}

Bài 3 — Tự viết: Hãy viết một khối JSON mô tả một đơn đặt bàn nhà hàng, gồm: mã đặt bàn, tên khách, số người (number), thời gian đặt, đã xác nhận hay chưa (boolean), và một danh sách (array) các món đặt trước. Áp dụng đúng các quy tắc đã học.

Bài 4 — Tư duy BA: Trong tình huống đặt bàn ở Bài 3, trường nào bạn cho phép null? Vì sao? Hãy viết một câu giải thích quy ước này như thể bạn đang ghi vào tài liệu đặc tả cho dev.

Tóm tắt

JSON là định dạng dữ liệu phổ biến nhất để truyền thông tin qua API, và nó chỉ là văn bản thuần được tổ chức theo cặp key-value. Bạn cần nắm vững: object dùng { } để mô tả một thực thể, array dùng [ ] để mô tả một danh sách, và các kiểu dữ liệu cơ bản gồm string, number, boolean, null. Key luôn nằm trong nháy kép, các cặp cách nhau bằng dấu phẩy và không có phẩy thừa ở cuối.

Quan trọng hơn cả cú pháp, với vai trò BA bạn cần đọc JSON dưới lăng kính nghiệp vụ: kiểu dữ liệu có đúng không, trường nào được phép null và null nghĩa là gì, array có cần quy tắc sắp xếp không. Như ba tình huống đã thấy, một BA đọc thông thạo JSON sẽ bắt lỗi sớm, viết đặc tả chính xác, và giao tiếp với đội kỹ thuật trơn tru hơn rất nhiều. Hãy luyện đọc JSON mỗi ngày — chỉ sau một thời gian ngắn, bạn sẽ "nhìn xuyên" được mọi khối dữ liệu mà không còn thấy rối. Ở các bài tiếp theo, chúng ta sẽ đi sâu hơn vào JSON lồng phức tạp, JSON Schema và so sánh với định dạng XML.