API là gì? Tại sao nó là "Trái tim" của mọi ứng dụng? (Hướng dẫn Postman từ A-Z) |TiiLaZ

Giới thiệu

Nếu bạn đang bắt đầu hành trình lập trình, chắc chắn bạn đã nghe thấy thuật ngữ API ở khắp mọi nơi. “Lấy API thời tiết”, “Gọi API của Google Map”, “API của Facebook”…

Nhưng API chính xác là gì? Tại sao nó lại quan trọng đến mức được gọi là “trái tim” của các ứng dụng hiện đại? Và làm thế nào chúng ta có thể kiểm tra xem “trái tim” đó có đang “đập” đúng nhịp hay không bằng một công cụ gọi là Postman (hoặc các công cụ khác)?

Trong bài viết này, Tiilaz sẽ giải thích mọi thứ từ A-Z: từ khái niệm cơ bản, vị trí của API trong một ứng dụng, cho đến lý do cần thiết phải xây dựng và sử dụng API, cùng hướng dẫn thực hành chi tiết.

Phần 1: API là gì? (Khái niệm)

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

API là viết tắt của Application Programming Interface (Giao diện lập trình ứng dụng).

Nghe có vẻ phức tạp, nhưng bạn có thể hiểu đơn giản: API là một người phục vụ trong nhà hàng.

Hãy tưởng tượng bạn (người dùng) đang ở trong một nhà hàng (một ứng dụng, ví dụ: Shopee). Bạn muốn gọi món (lấy dữ liệu, ví dụ: xem 10 sản phẩm mới nhất).

Bạn không thể tự mình xông vào bếp (cơ sở dữ liệu/máy chủ) để lấy đồ ăn.
Bạn cần gọi người phục vụ (API).
Bạn đưa ra yêu cầu cho người phục vụ: “Cho tôi xem 10 sản phẩm khuyến mãi” (Bạn nhấn vào một danh mục trên app).
Người phục vụ đi vào bếp, nói với đầu bếp (máy chủ) chuẩn bị “dữ liệu” đó.
Sau khi “dữ liệu” sẵn sàng, người phục vụ sẽ mang nó từ bếp ra cho bạn.

Trong thế giới kỹ thuật số:

Bạn (Client): Trình duyệt web (Chrome, Firefox), ứng dụng di động (app Shopee, app Facebook…).
Nhà bếp (Server / Backend): Máy chủ chứa dữ liệu và tất cả logic xử lý (xác thực, tính toán…).
Người phục vụ (API): Cầu nối trung gian nhận yêu cầu từ Client và gửi phản hồi từ Server.

Nói tóm lại: API là một bộ quy tắc và cơ chế cho phép các ứng dụng/chương trình khác nhau “nói chuyện” và trao đổi dữ liệu với nhau một cách rõ ràng.

Phần 2: API nằm ở đâu trong một ứng dụng?

Để hiểu rõ vai trò của API, chúng ta cần phân biệt các “khối” chính xây dựng nên một ứng dụng hiện đại.

1. Frontend (Giao diện người dùng)

Là gì? Đây là mọi thứ bạn nhìn thấy và tương tác trên màn hình. Nó là “mặt tiền” của cửa hàng.
Ví dụ: Giao diện website tiilaz.com bạn đang đọc, các nút bấm, hình ảnh, các biểu mẫu (form) đăng nhập.
Nhiệm vụ: Hiển thị dữ liệu đẹp mắt và gửi yêu cầu của người dùng đi.

2. Backend (Hệ thống máy chủ)

Là gì? Đây là “bộ não” và “nhà kho” nằm ẩn sau, xử lý mọi logic phức tạp. Nó là “nhà bếp” và “kho hàng”.
Ví dụ: Xác thực xem mật khẩu bạn nhập có đúng không, lưu bài viết mới vào cơ sở dữ liệu.

Sự khác biệt: Fullstack (Liền khối) vs. Backend API (Tách biệt)

Đây là lúc API thể hiện vai trò của mình:

Mô hình Fullstack (Liền khối): Trong một số ứng dụng (thường là kiểu cũ), Frontend và Backend được xây dựng dính liền với nhau. Khi bạn yêu cầu một trang, máy chủ (Backend) sẽ vừa xử lý logic, vừa “vẽ” ra trang HTML (Frontend) rồi gửi toàn bộ trang đó cho bạn.
- Vấn đề: Rất khó để có một ứng dụng di động (Mobile App) dùng chung “bộ não” này.
Mô hình Backend API (Tách biệt – Phổ biến hiện nay):
- Thay vì “vẽ” ra giao diện, Backend giờ đây chỉ cung cấp API.
- Backend chỉ nhận yêu cầu (ví dụ: “Lấy 10 bài viết”) và trả về dữ liệu thô (thường là dạng JSON). Nó không quan tâm dữ liệu đó sẽ được hiển thị màu gì, phông chữ gì.
- Frontend (website hoặc app di động) là một dự án hoàn toàn riêng biệt. Nó sẽ “gọi” đến Backend API để “xin” dữ liệu. Khi nhận được dữ liệu JSON, Frontend sẽ tự quyết định xem nên hiển thị nó như thế nào.

Chốt lại: Trong kiến trúc hiện đại, API chính là “bộ mặt” của Backend. Nó là cánh cửa giao tiếp duy nhất mà Backend mở ra cho thế giới bên ngoài (cho dù đó là Frontend “chính chủ” hay một đối tác khác).

Phần 3: Sự cần thiết của API (Tại sao “phải” dùng?)

Đây là phần quan trọng nhất. Tại sao người ta không làm liền khối cho nhanh mà lại phải mất công tách ra thành API?

A. Tại sao phải triển khai (xây dựng) API? (Góc nhìn Backend)

Nếu bạn là người viết Backend, việc bạn cung cấp API (thay vì tự “vẽ” HTML) là vô cùng cần thiết vì:

Hỗ trợ đa nền tảng (Web, Mobile, App…): Đây là lý do LỚN NHẤT. Bạn chỉ cần viết một bộ “não” (Backend API) một lần duy nhất. Sau đó:
- Team Web (dùng React, Vue…) sẽ gọi API này để hiển thị website.
- Team Mobile (dùng iOS, Android) cũng gọi chính API đó để hiển thị trên app di động.
- Bạn không cần viết lại logic xử lý cho mỗi nền tảng.
Cho phép đối tác/bên thứ ba kết nối (Tạo ra nền tảng):
- Shopee xây dựng API để các đơn vị vận chuyển (Giao Hàng Nhanh, J&T) có thể tự động cập nhật trạng thái đơn hàng vào hệ thống.
- Google Maps xây dựng API để Grab, Gojek có thể tích hợp bản đồ vào ứng dụng của họ.
- Các ngân hàng xây dựng API để MoMo, ZaloPay có thể thực hiện thanh toán.
Dễ dàng bảo trì và mở rộng:
- Khi Frontend và Backend tách biệt, hai đội nhóm có thể làm việc độc lập mà không ảnh hưởng lẫn nhau.
- Nếu website bị sập, app di động vẫn có thể hoạt động (và ngược lại).

B. Tại sao phải sử dụng (gọi) API? (Góc nhìn Frontend/Lập trình viên)

Nếu bạn là người làm Frontend hoặc phát triển ứng dụng, bạn sẽ liên tục phải sử dụng API vì:

Không phải “phát minh lại bánh xe”:
- Bạn muốn hiển thị bản đồ? Sử dụng API của Google Maps, không ai tự xây dựng hệ thống bản đồ từ đầu.
- Bạn muốn cho phép thanh toán online? Sử dụng API của MoMo, VNPay.
- Bạn muốn cho phép “Đăng nhập bằng Google”? Sử dụng API của Google.
Tập trung vào chuyên môn:
- Nếu bạn làm app thời tiết, chuyên môn của bạn là làm giao diện (UI/UX) thật đẹp. Bạn không cần tự xây dựng trạm dự báo, bạn chỉ cần gọi API từ một bên cung cấp dữ liệu thời tiết.
Để lấy dữ liệu “chính chủ”:
- Đây là trường hợp đơn giản nhất: Bạn là lập trình viên Frontend cho Tiilaz. Để hiển thị danh sách bài viết, bạn phải gọi API do chính team Backend của Tiilaz viết ra.

Phần 4: Tại sao phải kiểm tra API với Postman?

Khi API đã trở nên quan trọng như vậy (là “trái tim” cung cấp dữ liệu), chúng ta phải đảm bảo nó hoạt động chính xác.

Bạn (Frontend) gọi API “Lấy 10 bài viết” nhưng Backend trả về 5 bài? ==> Lỗi!
Bạn (Frontend) gửi thông tin đăng ký (POST) nhưng Backend báo lỗi 500 (lỗi máy chủ)? ==> Lỗi!

Postman là một công cụ giúp bạn “giả lập” làm Frontend để kiểm tra API.

Thay vì phải viết cả một website/ứng dụng di động chỉ để thử xem API có chạy không, bạn có thể dùng Postman để:

Gửi bất kỳ loại yêu cầu nào (GET, POST, PUT, DELETE…).
Gửi kèm dữ liệu (ví dụ: đăng ký tài khoản mới).
Xem phản hồi từ “nhà bếp” (Server) một cách chi tiết (dữ liệu, mã trạng thái, thời gian…).

Phần 5: Hướng dẫn kiểm tra API cơ bản với Postman

Chúng ta sẽ thực hành với một API công cộng miễn phí rất nổi tiếng tên là ReqRes (https://reqres.in/). Đây là một trang web cung cấp các API “giả” để lập trình viên thực hành.

Bước 1: Tải và cài đặt Postman

Bạn có thể tải phiên bản Postman cho máy tính (Windows, macOS, Linux) từ trang chủ của nó: https://www.postman.com/downloads/

Bước 2: Gửi yêu cầu đầu tiên (GET – Lấy dữ liệu)

GET là phương thức dùng để yêu cầu lấy (get) dữ liệu từ máy chủ.

Mở Postman. Nhấn vào nút “New” (hoặc dấu +) để tạo một yêu cầu mới.
Ở thanh địa chỉ (“Enter request URL”), nhập URL sau: https://reqres.in/api/users/2
Đảm bảo phương thức (method) được chọn ở bên trái là GET.
Nhấn nút Send màu xanh.

Kết quả:

Status (Trạng thái): Bạn sẽ thấy 200 OK. Đây là mã trạng thái HTTP báo hiệu “Mọi thứ thành công!”.
Body (Nội dung): Bạn sẽ thấy một đoạn mã JSON chứa thông tin của người dùng có ID là 2:

{
    "data": {
        "id": 2,
        "email": "janet.weaver@reqres.in",
        "first_name": "Janet",
        "last_name": "Weaver",
        "avatar": "https://reqres.in/img/faces/2-image.jpg"
    }
}

Bước 3: Gửi yêu cầu POST (Tạo dữ liệu mới)

POST là phương thức dùng để gửi (post) dữ liệu lên máy chủ, thường là để tạo một tài nguyên mới.

Tạo một yêu cầu mới (nhấn dấu +).
Đổi phương thức từ GET thành POST.
Nhập URL: https://reqres.in/api/users
Vì chúng ta cần gửi dữ liệu đi, hãy nhấp vào tab Body (bên dưới thanh URL).
Chọn tùy chọn raw.
Ở menu thả xuống bên phải, chọn JSON.
Trong khung văn bản lớn, nhập đoạn JSON sau:

{
    "name": "TiiLaz User",
    "job": "Learner"
}

Nhấn nút Send.

Kết quả:

Status (Trạng thái): Lần này bạn sẽ thấy 201 Created. Mã 201 có nghĩa là “Đã tạo thành công!”.
Body (Nội dung): Máy chủ sẽ trả về chính thông tin bạn vừa gửi, kèm theo một id mới:

{
    "name": "TiiLaz User",
    "job": "Learner",
    "id": "123",  // ID này sẽ thay đổi mỗi lần bạn gửi
    "createdAt": "2025-10-30T01:45:00.123Z" // Thời gian này cũng sẽ thay đổi
}

Phần 6: Bộ các API miễn phí để bạn thực hành (GET)

Bạn đã biết cách dùng GET và POST. Bây giờ, hãy thử “nghịch” thêm với các API công cộng (public) miễn phí khác. Chúng không cần đăng ký, chỉ cần copy đường dẫn, chọn GET trong Postman và nhấn Send!

1. JSONPlaceholder (Dữ liệu Giả Lập Cổ Điển)

Đây là API “kinh điển” để lấy các dữ liệu giả lập (bài post, bình luận, người dùng).

Lấy một bài post cụ thể (ID = 1): https://jsonplaceholder.typicode.com/posts/1
Lấy danh sách tất cả bài post: https://jsonplaceholder.typicode.com/posts
Lấy các bình luận của bài post số 1: https://jsonplaceholder.typicode.com/posts/1/comments

2. PokéAPI (Thế giới Pokémon)

Một API cực kỳ chi tiết cho bất kỳ ai yêu thích Pokémon.

Lấy thông tin của Pikachu: https://pokeapi.co/api/v2/pokemon/pikachu
Lấy thông tin của Ditto: https://pokeapi.co/api/v2/pokemon/ditto

3. Cat Facts (Thông tin về Mèo)

Một API đơn giản, mỗi lần gọi sẽ trả về một sự thật (fact) ngẫu nhiên về loài mèo.

Lấy một thông tin ngẫu nhiên về mèo: https://catfact.ninja/fact (Mỗi lần nhấn Send bạn sẽ nhận được một fact khác nhau)

4. The Bored API (Gợi ý khi chán)

Bạn đang chán và không biết làm gì? Hãy gọi API này!

Lấy một hoạt động ngẫu nhiên: https://www.boredapi.com/api/activity/

5. Open Library (API Sách)

Tìm thông tin về một cuốn sách bằng mã ISBN: https://openlibrary.org/api/books?bibkeys=ISBN:0201558025&format=json

6. OpenStreetMap Nominatim (API Bản đồ)

API này cho phép bạn “Geocoding” (tìm kiếm tọa độ từ một địa chỉ) một cách miễn phí.

Tìm kiếm thông tin vị trí của “Hà Nội”: https://nominatim.openstreetmap.org/search?q=Hanoi&format=json
Tìm kiếm thông tin vị trí của “Hồ Gươm”: https://nominatim.openstreetmap.org/search?q=Hoan+Kiem+Lake&format=json

Hãy thử các API này, xem cấu trúc JSON mà chúng trả về, và thử thay đổi các từ khóa (ví dụ: thay “pikachu” bằng “charmander”, hay “Hanoi” bằng “Da Nang”) để xem kết quả!

Phần 7: Bảo mật API: “Secret Key” là gì? (Authentication)

1. Tại sao lại cần “Secret Key”?

Trong các API thực hành ở trên, chúng ta có thể GET thoải mái. Nhưng trong thực tế, các hành động thay đổi dữ liệu (POST, PUT, DELETE) hầu như luôn luôn cần được bảo vệ.

“Nhà bếp” (Backend) sẽ luôn hỏi:

“Bạn là ai?” (Đây gọi là Authentication – Xác thực)
“Bạn có được phép làm việc này không?” (Đây gọi là Authorization – Ủy quyền)

Bạn không thể vào nhà hàng và yêu cầu DELETE món ăn của bàn bên cạnh. Bạn cũng không thể POST một bài viết lên blog Tiilaz nếu bạn không phải là Admin.

2. Các hình thức xác thực phổ biến

Để chứng minh bạn là ai, bạn cần một “Khóa bí mật”. Khi kiểm tra API, bạn sẽ thường gặp 2 dạng phổ biến nhất:

API Key: Một chuỗi ký tự (key) đơn giản mà máy chủ cấp cho bạn.
Bearer Token (Ví dụ: JWT): Đây là hình thức phổ biến nhất khi người dùng đăng nhập.
- Bạn dùng POST /login (gửi username/password) để đổi lấy một chuỗi Token.
- Bạn phải gửi kèm Token này cho tất cả các yêu cầu cần bảo vệ (như POST /posts hay DELETE /users/1).

3. Cách sử dụng “Secret Key” trong Postman

Làm thế nào để gửi kèm “khóa” này trong Postman? Hãy nhìn vào tab “Authorization” (nằm ngay dưới thanh URL).

Trong yêu cầu của bạn (ví dụ: DELETE /api/users/2), hãy nhấp vào tab Authorization.
Từ menu thả xuống Type, chọn “Bearer Token”.
Ở ô Token bên phải, hãy dán cái chuỗi Token mà bạn nhận được sau khi đăng nhập.
Bây giờ, nhấn Send.

Nếu bạn không gửi kèm thông tin xác thực, máy chủ sẽ trả về lỗi 401 Unauthorized (Bạn là ai vậy?) hoặc 403 Forbidden (Bạn không có quyền!).

Phần 8: Các khái niệm quan trọng khác khi kiểm tra API

Khi làm việc với Postman, bạn sẽ thường xuyên gặp các thuật ngữ này:

HTTP Methods (Phương thức):
- GET: Lấy dữ liệu.
- POST: Tạo dữ liệu mới.
- PUT / PATCH: Cập nhật dữ liệu.
- DELETE: Xóa dữ liệu.
Status Codes (Mã trạng thái): “Câu trả lời” của người phục vụ.
- 2xx (Thành công): 200 OK, 201 Created.
- 4xx (Lỗi từ phía bạn – Client):
  - 400 Bad Request: Yêu cầu sai (ví dụ: gửi thiếu email).
  - 401 Unauthorized: Bạn chưa đăng nhập (chưa xác thực).
  - 403 Forbidden: Bạn đã đăng nhập nhưng không có quyền.
  - 404 Not Found: Không tìm thấy tài nguyên.
- 5xx (Lỗi từ máy chủ – Server):
  - 500 Internal Server Error: “Nhà bếp” bị cháy.
Collections (Bộ sưu tập): Một thư mục trong Postman để bạn lưu lại các yêu cầu API của mình (ví dụ: Collection “Quản lý Người dùng”) để kiểm tra lại sau này.

Phần 9: Có thể dùng công cụ khác thay cho Postman không?

Câu trả lời là chắc chắn CÓ. Postman là công cụ phổ biến nhất, nhưng không phải là duy nhất:

1. Sử dụng chính Trình duyệt (và DevTools)

Với yêu cầu GET: Bạn hoàn toàn có thể! Chỉ cần dán một đường dẫn API GET vào thanh địa chỉ trình duyệt, nhấn Enter.
Hạn chế: Bạn không thể dùng trình duyệt để gửi yêu cầu POST, PUT, DELETE một cách trực tiếp.
Công cụ Lập trình viên (F12 DevTools): Nhấn F12 và chọn tab “Network” (Mạng) để theo dõi tất cả các API mà website đó đang gọi.

2. Các ứng dụng GUI tương tự (Đối thủ trực tiếp)

Insomnia: Giao diện được nhiều người đánh giá là sạch sẽ, gọn gàng hơn.
Hoppscotch.io (trước đây là Postwoman): Một lựa chọn tuyệt vời vì nó chạy trực tiếp trên trình duyệt web, không cần cài đặt.

3. Tiện ích mở rộng trong IDE (Ví dụ: VS Code)

Thunder Client: Một tiện ích mở rộng (extension) cực kỳ nổi tiếng cho Visual Studio Code, hoạt động gần giống Postman ngay trong trình soạn thảo code của bạn.

4. Công cụ Dòng lệnh (Terminal)

cURL: “Ông tổ” của các công cụ kiểm tra API, có sẵn trên hầu hết các hệ điều hành.

Vậy tại sao Postman vẫn phổ biến? Vì nó cân bằng được sự thân thiện cho người mới (giao diện trực quan) và các tính năng nâng cao (viết test script, chia sẻ collection) cho các đội nhóm lớn.

Phần 10: Kết luận

API không phải là một thứ gì đó quá xa vời, nó chính là “người phục vụ” hay “trái tim” cung cấp dữ liệu, là xương sống của hầu hết các ứng dụng hiện đại.

Qua bài viết này, bạn đã hiểu được:

API là gì: Là trung gian giao tiếp giữa Client (Frontend) và Server (Backend).
Kiến trúc ứng dụng: API là trung tâm của mô hình Backend và Frontend tách biệt.
Sự cần thiết: Chúng ta triển khai API để hỗ trợ đa nền tảng (web, mobile) và sử dụng API của bên thứ ba để tiết kiệm thời gian.
Thực hành: Bạn đã có một danh sách API (JSONPlaceholder, PokéAPI, API Bản đồ…) để tự mình thực hành GET.
Bảo mật API: Các hành động quan trọng (POST, PUT, DELETE) luôn cần Xác thực (ví dụ: Bearer Token).
Công cụ kiểm tra: Postman là công cụ tuyệt vời để bắt đầu, bên cạnh đó còn có Insomnia, Hoppscotch hay Thunder Client.

Biết cách kiểm tra API (bao gồm cả các API cần xác thực) là một kỹ năng thiết yếu cho mọi vị trí trong ngành lập trình, từ Frontend, Backend đến Tester.

API là gì? Tại sao nó là “Trái tim” của mọi ứng dụng? (Hướng dẫn Postman từ A-Z)