Courses
API là xương sống của các ứng dụng web và di động hiện đại. Gần như mọi ứng dụng trên điện thoại và mọi trang web bạn truy cập đều dùng API để lấy và tương tác với dữ liệu hiển thị trên màn hình.
REST và GraphQL là hai mô hình thiết kế API phổ biến nhất. Hướng dẫn này sẽ khám phá những khác biệt cốt lõi, lợi ích và trường hợp sử dụng phù hợp của cả hai, để bạn có thể chọn cách tiếp cận phù hợp nhất cho dự án của mình.
Khoan đã, API là gì?
Nếu bạn hoàn toàn mới với khái niệm API (Application Programming Interface), hãy cân nhắc tham gia khóa Streamlined Data Ingestion with Pandas. Khóa học sẽ dạy bạn cách các ứng dụng tận dụng API để giao tiếp với các chương trình khác - và ngược lại - mà không bên nào cần biết nội tình của bên kia. Khóa học sẽ giúp bạn thành thạo các quy tắc và giao thức mà ứng dụng sử dụng để yêu cầu và trao đổi thông tin.
REST là gì?
REST (Representational State Transfer) là một phong cách kiến trúc được sử dụng để phát triển dịch vụ web từ đầu những năm 2000. Nó xác định một tập hợp các ràng buộc và nguyên tắc để xây dựng API có khả năng mở rộng và không trạng thái. REST API (còn gọi là RESTful API) được thiết kế gọn nhẹ và có thể dùng với bất kỳ ngôn ngữ hay nền tảng nào hỗ trợ HTTP.
Nếu bạn mới làm quen với REST API, tôi khuyên bạn nên tập tương tác với chúng trước khi tự phát triển. Điều đó sẽ giúp bạn cảm nhận cách chúng hoạt động và các thực tiễn tốt nhất. Hãy xem Intermediate Importing Data in Python hoặc Intermediate Importing Data in R để bắt đầu. Cả hai khóa đều có chương về gửi yêu cầu HTTP, thu thập dữ liệu web và nhiều điều thú vị khác.
Khái niệm chính của REST API
Hãy cùng tìm hiểu các khái niệm của REST.
Không trạng thái
Mỗi tương tác giữa client và server là độc lập. Server không lưu trữ dữ liệu phiên liên quan đến client giữa các yêu cầu, nghĩa là mọi yêu cầu từ client đến server đều phải chứa tất cả thông tin cần thiết để hiểu và xử lý yêu cầu đó.
Dựa trên tài nguyên
Mọi dữ liệu hay chức năng đều được coi là một tài nguyên có thể được nhận diện và thao tác thông qua một định danh duy nhất, thường là URI (Uniform Resource Identifier).
Ví dụ, trong một ứng dụng thương mại điện tử, tài nguyên có thể bao gồm khách hàng, sản phẩm, đơn hàng, v.v. Mỗi tài nguyên được nhận diện bằng một URI duy nhất hoạt động như một địa chỉ nơi có thể truy cập tài nguyên. Ví dụ:
-
/productscó thể chỉ tập hợp tất cả sản phẩm. -
/products/123có thể chỉ một sản phẩm cụ thể với ID123.
Phương thức HTTP
RESTful API thường sử dụng các phương thức HTTP tiêu chuẩn để thao tác với tài nguyên:
-
GET: Truy xuất dữ liệu từ server (ví dụ: lấy danh sách sản phẩm). -
POST: Gửi dữ liệu lên server (ví dụ: tạo sản phẩm mới). -
PUT: Cập nhật một tài nguyên hiện có (ví dụ: sửa thông tin sản phẩm). -
DELETE: Xóa một tài nguyên (ví dụ: xóa sản phẩm).
Một yêu cầu GET tiêu chuẩn sẽ trông như sau:

Ví dụ yêu cầu và phản hồi REST. Ảnh: Tác giả.
REST API cũng sử dụng các mã trạng thái HTTP tiêu chuẩn để truyền đạt lỗi, thành công và các phản hồi khác. Và đúng vậy, trạng thái 418 I’m a teapot là có thật!
Định dạng dữ liệu
RESTful API có thể dùng nhiều định dạng để biểu diễn và trao đổi dữ liệu, bao gồm JSON, XML, HTML, Văn bản thuần, YAML và CSV.
GraphQL là gì?
GraphQL là ngôn ngữ truy vấn và môi trường chạy mã nguồn mở cho API, cho phép client yêu cầu chính xác dữ liệu họ cần và không hơn. Ban đầu nó được Meta (trước đây là Facebook) phát triển nội bộ vào năm 2012 để tối ưu việc lấy dữ liệu cho ứng dụng di động và phát hành công khai vào năm 2015.
Khái niệm chính của GraphQL API
Hãy xem các ý tưởng chính trong GraphQL.
Truy vấn theo nhu cầu client
Trong GraphQL, client xác định cấu trúc phản hồi bằng cách chỉ rõ các trường họ cần trong truy vấn. Điều này nghĩa là client có thể chỉ yêu cầu dữ liệu cụ thể, tránh lấy thừa (nhận quá nhiều dữ liệu) và lấy thiếu (nhận không đủ dữ liệu).
Trong GraphQL, một truy vấn để lấy chi tiết người dùng sẽ trông như sau:

Ví dụ yêu cầu và phản hồi GraphQL. Ảnh: Tác giả.
Queries và mutations
Trong khi queries dùng để đọc dữ liệu, mutations dùng để ghi hoặc sửa dữ liệu. Mutations trong GraphQL tương tự các thao tác POST, PUT và DELETE trong REST.
Một endpoint duy nhất
Không giống REST API có thể có nhiều endpoint cho các tài nguyên khác nhau, GraphQL thường chỉ cung cấp một endpoint. Endpoint này xử lý tất cả queries và mutations, giúp client tương tác với API đơn giản hơn.
Schema kiểu mạnh
GraphQL API được định nghĩa bởi một schema, là đặc tả kiểu mạnh của các mô hình dữ liệu có sẵn và mối quan hệ giữa chúng. Schema này đóng vai trò hợp đồng giữa client và server, đảm bảo dữ liệu trả về khớp với yêu cầu của client và đúng kiểu mong đợi.
Tự mô tả (Introspection)
Schema của GraphQL có khả năng tự mô tả. Client có thể dùng tính năng introspection để truy vấn chính schema và khám phá các kiểu, queries, mutations và subscriptions có sẵn, giúp việc tìm hiểu và nắm bắt API dễ dàng hơn.
Dữ liệu thời gian thực
GraphQL hỗ trợ cập nhật dữ liệu thời gian thực thông qua subscriptions. Subscriptions cho phép client nhận cập nhật bất cứ khi nào dữ liệu họ quan tâm thay đổi, hữu ích cho các ứng dụng thời gian thực như chat hoặc luồng tin trực tiếp.
Khác biệt chính giữa GraphQL và REST
Bảng dưới đây tóm tắt những khác biệt chính giữa GraphQL và REST API.
| Khía cạnh | REST | GraphQL |
|---|---|---|
| Bản chất | Kiến trúc | Ngôn ngữ truy vấn |
| Lấy dữ liệu | Nhiều endpoint cho các tài nguyên khác nhau (/products/123, /users/userA, v.v.) | Một endpoint duy nhất với truy vấn linh hoạt. |
| Phiên bản | Thường quản lý phiên bản qua URL (ví dụ: /api/v1/). | Không có phiên bản; thay đổi được quản lý bằng cách tiến hóa schema và giữ tương thích. |
| Kiểu dữ liệu | Không được định nghĩa chặt chẽ; client có thể nhận các định dạng dữ liệu khác nhau. | Schema kiểu mạnh định nghĩa rõ cấu trúc và kiểu dữ liệu. |
| Xử lý lỗi | Sử dụng mã trạng thái HTTP để chỉ báo lỗi. | Lỗi được trả trong thân phản hồi. Vẫn sử dụng mã trạng thái HTTP. |
Ưu và nhược điểm của GraphQL và REST
Như hầu hết mọi thứ trong cuộc sống, mỗi giải pháp đều có ưu và nhược điểm.
| Loại API | Ưu điểm | Nhược điểm |
|---|---|---|
| REST | - Dễ học: Quen thuộc với các nhà phát triển có kinh nghiệm web. - Công cụ trưởng thành: Tài liệu phong phú và thực tiễn bảo mật (OAuth, khóa API). |
- Lấy thừa/thiếu: Có thể dẫn đến truy xuất dữ liệu kém hiệu quả. - Phiên bản: Cần nhiều phiên bản API. - Không có cập nhật thời gian thực gốc: Cần công nghệ bổ sung như WebSocket. |
| GraphQL | - Lấy dữ liệu hiệu quả: Một yêu cầu lấy đúng dữ liệu cần thiết. - Tự mô tả: Schema tự động là tài liệu luôn cập nhật. - Cập nhật thời gian thực: Hỗ trợ subscriptions để đồng bộ tức thì. |
- Độ khó học cao: Phức tạp hơn để nắm vững. - Phức tạp khi lưu vào bộ nhớ đệm: Bộ nhớ đệm HTTP tiêu chuẩn không hiệu quả; cần bộ nhớ đệm tùy chỉnh. - Rủi ro bảo mật: Truy vấn linh hoạt có thể dẫn đến rò rỉ dữ liệu ngoài ý muốn. |
Lựa chọn giữa GraphQL và REST

Việc chọn REST hay GraphQL sẽ hoàn toàn phụ thuộc vào nhu cầu của dự án. Có lẽ bạn đã có linh cảm dựa trên phần trước, nhưng theo kinh nghiệm, bạn nên dùng REST khi:
- Mô hình dữ liệu đơn giản
- Ứng dụng cần lưu vào bộ nhớ đệm nhiều.
- Nhóm quen thuộc với quy ước REST.
- Cần phản hồi có tính dự đoán và tiêu chuẩn hóa.
Và dùng GraphQL khi bạn xử lý:
- Mô hình dữ liệu phức tạp với quan hệ lồng nhau.
- Ứng dụng cần truy vấn linh hoạt, động.
- Lặp nhanh và giảm điều chỉnh backend.
- Cập nhật thời gian thực.
REST và GraphQL cũng có thể được dùng cùng nhau trong giải pháp lai, để dự án của bạn vừa hưởng lợi từ các endpoint REST đơn giản, rõ ràng vừa có sự linh hoạt của GraphQL cho truy xuất dữ liệu phức tạp. Chẳng hạn, trong ứng dụng thương mại điện tử, bạn có thể dùng REST cho xác thực và đăng ký người dùng để tận dụng các thực tiễn bảo mật chuẩn như OAuth, và dùng GraphQL để lấy thông tin lồng và phức tạp hơn như chi tiết sản phẩm, danh mục và đánh giá người dùng.
Kết luận
Tóm lại: cả GraphQL và REST đều có điểm mạnh và điểm yếu, phù hợp với các bối cảnh khác nhau. Việc lựa chọn nên dựa trên yêu cầu dự án và mức độ phức tạp của dữ liệu.
Dù vậy, cả hai công cụ đều rất thú vị để làm việc và có thể dạy bạn nhiều điều về dữ liệu, nên nếu có cơ hội, tôi khuyên bạn hãy thử chúng vào lúc nào đó!
Và nếu sau khi đọc bài này, bạn biết mình muốn dùng công cụ nào, thì bạn đã sẵn sàng cho bước tiếp theo! Hãy xem bài viết Mastering API Design: Essential Strategies for Developing High-Performance APIs của chúng tôi để học cách thiết kế API của riêng bạn.

Tôi là một trưởng nhóm kỹ thuật định hướng sản phẩm, chuyên giúp các startup giai đoạn đầu phát triển từ nguyên mẫu đầu tiên đến khi đạt được sự phù hợp sản phẩm - thị trường và xa hơn nữa. Tôi luôn tò mò về cách con người sử dụng công nghệ, và tôi thích làm việc sát sao với nhà sáng lập và các nhóm liên chức năng để biến những ý tưởng táo bạo thành hiện thực. Khi không xây dựng sản phẩm, tôi tìm cảm hứng ở những miền đất mới hoặc xả căng thẳng tại phòng tập yoga.
Câu hỏi thường gặp
Tôi có thể dễ dàng chuyển từ REST sang GraphQL hoặc ngược lại không?
Đáng tiếc là không có câu trả lời ngắn gọn cho câu hỏi này. Điều đó thực sự phụ thuộc vào yêu cầu của dự án, nên có thể đơn giản hoặc rất phức tạp. Từ REST sang GraphQL: Bạn sẽ cần thiết kế một schema GraphQL, chuyển các endpoint REST thành queries và mutations của GraphQL, và điều chỉnh logic backend. Từ GraphQL sang REST: Việc này bao gồm tạo nhiều endpoint REST, điều chỉnh phương thức lấy dữ liệu, và triển khai chiến lược phiên bản hóa và lưu vào bộ nhớ đệm.
Có những công cụ và thư viện nào để làm việc với GraphQL và REST?
Với REST, có rất nhiều thư viện và framework lâu đời như Express.js, Django REST framework, Flask-RESTful và Spring Boot. Chúng cung cấp hỗ trợ toàn diện để xây dựng và sử dụng RESTful API. Với GraphQL, các thư viện và công cụ phổ biến gồm Apollo Server, GraphQL.js, Relay và Graphene (cho Python). Những thư viện này được dùng để định nghĩa schema, thực thi truy vấn và giao tiếp client-server.
Ngoài REST và GraphQL còn có mô hình thiết kế API nào khác không?
Có, các mô hình thiết kế API khác bao gồm SOAP (Simple Object Access Protocol) và gRPC (gRPC Remote Procedure Call). SOAP là một giao thức dùng XML để định dạng thông điệp và phụ thuộc nhiều vào các tiêu chuẩn dịch vụ web, phù hợp cho ứng dụng cấp doanh nghiệp đòi hỏi bảo mật cao và độ tin cậy giao dịch. gRPC (do Google phát triển) sử dụng HTTP/2 để truyền tải, Protocol Buffers để tuần tự hóa, và mang lại lợi ích hiệu năng với các tính năng như multiplexing, streaming hai chiều và sinh mã tích hợp sẵn.
Có thể dùng REST và GraphQL cùng trong một ứng dụng không?
Có, REST và GraphQL có thể được dùng cùng nhau theo cách tiếp cận lai. Ví dụ, REST có thể xử lý các endpoint đơn giản, rõ ràng như xác thực và đăng ký người dùng, sử dụng các thực tiễn bảo mật đã được kiểm chứng. GraphQL có thể đảm nhiệm các tác vụ truy xuất dữ liệu phức tạp hơn, như lấy thông tin lồng nhau hoặc liên quan.
Những trường hợp sử dụng điển hình cho cập nhật dữ liệu thời gian thực của GraphQL là gì?
Cập nhật dữ liệu thời gian thực của GraphQL đặc biệt hữu ích cho các ứng dụng cần đồng bộ tức thì như ứng dụng chat, cập nhật tỷ số thể thao trực tiếp, bảng giá chứng khoán, chỉnh sửa tài liệu cộng tác và bất kỳ kịch bản nào khác cần đẩy thay đổi dữ liệu đến client ngay lập tức.