API là gì? Giải thích REST và GraphQL cho Lập trình viên

Table of Contents

Thách thức: Khiến Phần mềm Giao tiếp

Là một kỹ sư IT, tôi đã dành nhiều năm xây dựng các hệ thống nơi các thành phần phần mềm khác nhau phải giao tiếp liền mạch. Các thành phần này thường chạy trên các máy chủ riêng biệt hoặc thậm chí là các nền tảng hoàn toàn khác nhau. Hãy tưởng tượng một ứng dụng di động lấy dữ liệu người dùng từ một máy chủ backend, hoặc một ứng dụng web hiển thị thông tin sản phẩm từ cơ sở dữ liệu. Làm thế nào để những mảnh ghép phần mềm riêng lẻ này hiểu nhau và trao đổi thông tin một cách đáng tin cậy?

Giao tiếp giữa các ứng dụng đặt ra một thách thức cơ bản trong phát triển phần mềm hiện đại. Nếu không có một cách thức tiêu chuẩn để các hệ thống tương tác, mọi tích hợp sẽ nhanh chóng trở thành một mớ hỗn độn tùy chỉnh, dễ đổ vỡ. Đây chính xác là vấn đề mà các API được thiết kế để giải quyết, và việc giải quyết nó một cách hiệu quả đã trở nên quan trọng hơn bao giờ hết.

Các Khái niệm Cốt lõi: Giải mã API, REST và GraphQL

API chính xác là gì?

API, hay Giao diện Lập trình Ứng dụng (Application Programming Interface), đơn giản là một tập hợp các quy tắc và định nghĩa. Nó cho phép các ứng dụng phần mềm khác nhau giao tiếp với nhau. Đóng vai trò là một bên trung gian, API định nghĩa các phương thức và định dạng dữ liệu mà các ứng dụng có thể sử dụng để yêu cầu và trao đổi thông tin.

Hãy tưởng tượng bạn đang gọi món ăn tại một nhà hàng. Với tư cách là khách hàng, bạn không đi vào bếp để tự chuẩn bị bữa ăn của mình. Thay vào đó, bạn xem thực đơn (tài liệu API) để biết những gì có sẵn. Sau đó, bạn nói với người phục vụ (endpoint API) món bạn muốn gọi. Người phục vụ mang yêu cầu của bạn vào bếp (máy chủ), nơi thức ăn được chuẩn bị và mang trở lại cho bạn. Bạn nhận được chính xác những gì bạn yêu cầu, mà không cần phải biết chi tiết phức tạp về hoạt động của nhà bếp.

Trong thế giới phần mềm, điều này có nghĩa là một ứng dụng di động có thể yêu cầu danh sách người dùng từ một máy chủ. Tương tự, một dịch vụ web có thể gửi chi tiết thanh toán đến một cổng thanh toán. Không ứng dụng nào cần hiểu cách hoạt động nội bộ của ứng dụng kia; chúng chỉ cần đồng ý với hợp đồng của API.

Từ kinh nghiệm thực tế của tôi, việc xây dựng và thành thạo API là một kỹ năng thiết yếu. Chúng tạo thành xương sống của hầu hết mọi hệ thống phân tán mà bạn sẽ gặp, từ kiến trúc microservices cho đến việc tích hợp các dịch vụ của bên thứ ba.

API RESTful: Tiêu chuẩn Công nghiệp

REST, viết tắt của Representational State Transfer, là một phong cách kiến trúc để thiết kế các ứng dụng mạng. Nó không phải là một giao thức hay một tiêu chuẩn, mà là một tập hợp các ràng buộc. Khi được áp dụng, các ràng buộc này dẫn đến một hệ thống đơn giản, có khả năng mở rộng và không trạng thái.

Một API RESTful (thường được gọi là REST API) sử dụng các phương thức HTTP tiêu chuẩn như GET, POST, PUT và DELETE để thực hiện các thao tác trên các tài nguyên (resource). Các tài nguyên thường được xác định bằng các URL (Uniform Resource Locator) duy nhất. Ví dụ, nếu bạn có một tập hợp các ‘bài đăng’, bạn có thể tương tác với chúng như sau:

GET /posts: Lấy danh sách tất cả bài đăng.
GET /posts/123: Lấy bài đăng có ID 123.
POST /posts: Tạo một bài đăng mới.
PUT /posts/123: Cập nhật bài đăng có ID 123.
DELETE /posts/123: Xóa bài đăng có ID 123.

Dữ liệu thường được trao đổi ở định dạng JSON, mặc dù XML cũng phổ biến. REST API là stateless (không trạng thái), nghĩa là mỗi yêu cầu của client gửi đến máy chủ chứa tất cả thông tin cần thiết để máy chủ hiểu được. Máy chủ không lưu trữ bất kỳ ngữ cảnh nào của client giữa các yêu cầu.

Ưu điểm của REST:

Đơn giản: Dễ hiểu và triển khai, tận dụng các phương thức HTTP hiện có.
Phổ biến rộng rãi: Hưởng lợi từ các công cụ và sự hỗ trợ cộng đồng phong phú.
Có thể cache: Các cơ chế HTTP caching có thể cải thiện đáng kể hiệu suất cho các yêu cầu GET.

Nhược điểm của REST:

Over-fetching/Under-fetching: Client thường nhận nhiều dữ liệu hơn mức cần thiết (over-fetching) hoặc phải thực hiện nhiều yêu cầu để thu thập tất cả dữ liệu cần thiết (under-fetching).
Nhiều Endpoint: Khi ứng dụng mở rộng, việc quản lý nhiều endpoint khác nhau có thể làm phức tạp quá trình phát triển phía client.

GraphQL: Ngôn ngữ Truy vấn cho API

GraphQL là một ngôn ngữ truy vấn và thao tác dữ liệu mã nguồn mở dành cho API, cùng với một runtime để thực hiện các truy vấn đó với dữ liệu hiện có của bạn. Facebook đã phát triển nó vào năm 2012 và phát hành công khai vào năm 2015.

Ý tưởng cốt lõi đằng sau GraphQL là trao quyền cho client yêu cầu chính xác những gì nó cần và không hơn. Thay vì nhiều endpoint, một GraphQL API thường chỉ cung cấp một endpoint duy nhất. Client gửi một truy vấn (một chuỗi mô tả các yêu cầu dữ liệu của chúng) đến endpoint này, và máy chủ sẽ phản hồi bằng một đối tượng JSON chứa chính xác dữ liệu được yêu cầu.

Hãy xem lại ví dụ về ‘bài đăng’. Với GraphQL, bạn có thể truy vấn các bài đăng và tác giả của chúng, chỉ định các trường bạn cần:


query {
  post(id: "123") {
    title
    content
    author {
      name
      email
    }
  }
}

Sự linh hoạt này cho phép client lấy tất cả dữ liệu cần thiết chỉ trong một yêu cầu duy nhất. Do đó, nó làm giảm chi phí mạng và cải thiện hiệu suất, đặc biệt đối với các ứng dụng di động hoặc giao diện người dùng phức tạp.

Ưu điểm của GraphQL:

Truy xuất dữ liệu hiệu quả: Loại bỏ tình trạng over-fetching và under-fetching. Client nhận chính xác những gì họ yêu cầu.
Endpoint duy nhất: Đơn giản hóa mã phía client bằng cách tương tác với một URL.
Schema được định kiểu mạnh: Cung cấp một hợp đồng rõ ràng giữa client và server, cho phép các công cụ phát triển mạnh mẽ và khả năng kiểm tra hợp lệ.
Khả năng thời gian thực: Hỗ trợ tích hợp cho các subscription cho phép client nhận các cập nhật theo thời gian thực.

Nhược điểm của GraphQL:

Đường cong học tập: Yêu cầu phải hiểu một ngôn ngữ truy vấn và định nghĩa schema mới.
Phức tạp trong Caching: Việc caching có thể phức tạp hơn so với REST, vì các yêu cầu không dựa trên các URL HTTP tiêu chuẩn.
Tải file lên: Triển khai chức năng tải file lên có thể kém trực quan hơn so với REST.
Vấn đề N+1: Nếu không được triển khai cẩn thận, việc lấy dữ liệu liên quan có thể dẫn đến nhiều truy vấn cơ sở dữ liệu.

REST so với GraphQL: So sánh Trực tiếp

Dưới đây là tổng quan nhanh về cách hai phong cách kiến trúc này so sánh với nhau:

Tính năng	REST	GraphQL
Kiến trúc	Nhiều endpoint cho các tài nguyên khác nhau	Endpoint duy nhất cho tất cả các yêu cầu dữ liệu
Truy xuất dữ liệu	Cấu trúc dữ liệu cố định cho mỗi endpoint (thường gặp over/under-fetching)	Client chỉ định chính xác dữ liệu cần (không over/under-fetching)
Phương thức HTTP	Tận dụng các phương thức HTTP tiêu chuẩn (GET, POST, PUT, DELETE)	Chủ yếu sử dụng POST cho các truy vấn và mutation
Caching	Hỗ trợ HTTP caching gốc	Yêu cầu các giải pháp caching tùy chỉnh hoặc caching phía client
Độ phức tạp	Thường đơn giản hơn cho các trường hợp sử dụng cơ bản	Đường cong học tập ban đầu cao hơn, nhưng mạnh mẽ hơn cho các nhu cầu phức tạp
Phát triển API	Thường yêu cầu versioning cho các thay đổi gây phá vỡ	Linh hoạt hơn; client chỉ bị lỗi nếu các trường họ sử dụng bị xóa
Thời gian thực	Yêu cầu WebSockets hoặc polling cho các cập nhật thời gian thực	Subscription tích hợp cho dữ liệu thời gian thực

Thực hành: Tương tác với API

Hãy cùng khám phá một số ví dụ thực tế về cách bạn tương tác với cả REST API và GraphQL API.

Gọi một REST API

Chúng ta sẽ sử dụng JSONPlaceholder, một API giả miễn phí để kiểm thử và tạo mẫu, để minh họa một lời gọi REST API đơn giản. Mục tiêu của chúng ta là lấy một bài đăng theo ID của nó.

Sử dụng curl:


curl https://jsonplaceholder.typicode.com/posts/1

Đầu ra:


{
  "userId": 1,
  "id": 1,
  "title": "sunt aut facere repellat provident occaecati excepturi optio reprehenderit",
  "body": "quia et suscipit\nsuscipit recusandae consequuntur expedita et cum\nreprehenderit molestiae ut ut quas totam\nnostrum rerum est autem sunt rem eveniet architecto"
}

Lưu ý rằng chúng ta đã nhận được tất cả các trường cho bài đăng (userId, id, title, body), mặc dù chúng ta có thể chỉ muốn tiêu đề. Điều này minh họa tình trạng over-fetching.

Sử dụng Python requests:


import requests

url = "https://jsonplaceholder.typicode.com/posts/1"
response = requests.get(url)

if response.status_code == 200:
    post_data = response.json()
    print(f"Tiêu đề bài đăng: {post_data['title']}")
    print(f"Nội dung bài đăng: {post_data['body']}")
else:
    print(f"Lỗi: {response.status_code}")

Truy vấn một GraphQL API

Đối với GraphQL, chúng ta sẽ truy vấn một API công khai như Countries API (countries.trevorblades.com). Chúng ta sẽ lấy dữ liệu về một quốc gia cụ thể, chỉ yêu cầu các trường chúng ta thực sự cần.

Sử dụng curl:


curl -X POST \
  -H "Content-Type: application/json" \
  --data '{"query": "query { country(code: \"BR\") { name capital emoji } }"}' \
  https://countries.trevorblades.com/

Đầu ra:


{
  "data": {
    "country": {
      "name": "Brazil",
      "capital": "Brasília",
      "emoji": "🇧🇷"
    }
  }
}

Ở đây, chúng ta đã yêu cầu rõ ràng name, capital và emoji cho Brazil. Và đó chính xác là những gì chúng ta nhận được — không có dữ liệu thừa, thể hiện rõ ràng hiệu quả của GraphQL.

Sử dụng Python requests:


import requests
import json

url = "https://countries.trevorblades.com/"
query = """
query {
  country(code: "BR") {
    name
    capital
    emoji
  }
}
"""

headers = {"Content-Type": "application/json"}
data = {'query': query}

response = requests.post(url, headers=headers, data=json.dumps(data))

if response.status_code == 200:
    country_data = response.json().get('data', {}).get('country')
    if country_data:
        print(f"Tên quốc gia: {country_data['name']}")
        print(f"Thủ đô: {country_data['capital']}")
        print(f"Biểu tượng cảm xúc: {country_data['emoji']}")
    else:
        print("Không tìm thấy quốc gia hoặc lỗi truy vấn.")
else:
    print(f"Lỗi: {response.status_code}")

Kết luận

Hiểu cách các ứng dụng giao tiếp thông qua API là một nền tảng của phát triển phần mềm hiện đại. Cả REST và GraphQL đều cung cấp những cách mạnh mẽ để xây dựng và sử dụng API, mỗi loại đều có những ưu điểm và nhược điểm riêng biệt.

REST, với sự đơn giản và tuân thủ các tiêu chuẩn HTTP, vẫn là một lựa chọn tuyệt vời cho việc xây dựng các API định hướng tài nguyên. Nó đặc biệt hữu ích khi xử lý dữ liệu tương đối tĩnh, hoặc khi khả năng tương thích rộng rãi của client và caching là tối quan trọng. REST đã trưởng thành, được hiểu rõ và sở hữu một hệ sinh thái rộng lớn.

Ngược lại, GraphQL tỏa sáng khi sự linh hoạt phía client và việc truy xuất dữ liệu hiệu quả là yếu tố then chốt. Nếu ứng dụng của bạn có yêu cầu dữ liệu phức tạp, giao diện người dùng thường xuyên thay đổi, hoặc cần giảm thiểu các yêu cầu mạng (ví dụ: ứng dụng di động), GraphQL có thể là một lựa chọn tuyệt vời. Nó cho phép client xác định chính xác nhu cầu dữ liệu của họ, mang lại cho nhà phát triển nhiều quyền kiểm soát hơn và giảm gánh nặng quản lý nhiều endpoint.

Cuối cùng, quyết định sử dụng REST hay GraphQL phụ thuộc vào các yêu cầu cụ thể của dự án, sự quen thuộc của nhóm bạn với các công nghệ, và bản chất của dữ liệu bạn đang cung cấp.

Nhiều ứng dụng hiện đại thậm chí còn áp dụng phương pháp kết hợp, sử dụng REST cho các tương tác đơn giản hơn, dựa trên tài nguyên và GraphQL cho các nhu cầu dữ liệu phức tạp hơn, do client điều khiển. Cả hai đều là những công cụ vô cùng giá trị trong bộ công cụ của một kỹ sư IT, và việc biết khi nào và cách áp dụng chúng một cách hiệu quả là một kỹ năng thực sự mang lại lợi ích lớn.