Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Node.js

Viết API đầu tiên của bạn bằng Node.js và Express: Tìm hiểu về REST API

by
Difficulty:BeginnerLength:MediumLanguages:
This post is part of a series called Code Your First API With Node.js and Express.
Code Your First API With Node.js and Express: Set Up the Server

Vietnamese (Tiếng Việt) translation by Dai Phong (you can also view the original English article)

Tìm hiểu về REST và RESTful API

Nếu bạn đã từng dành gian cho việc phát triển web hiện đại, bạn sẽ gặp các thuật ngữ như REST và API. Nếu bạn đã từng nghe về các thuật ngữ này hoặc từng làm việc với các API nhưng không hiểu đầy đủ về cách chúng hoạt động hoặc cách xây dựng API của riêng bạn, thì loạt bài này là dành cho bạn.

Trong loạt bài hướng dẫn này, chúng ta sẽ bắt đầu với cái nhìn tổng quan về các nguyên tắc và khái niệm REST. Sau đó, chúng ta sẽ tiếp tục tạo API cho riêng mình, chạy trên máy chủ Node.js Express và kết nối với cơ sở dữ liệu MySQL. Sau khi hoàn thành loạt bài này, bạn sẽ có khả năng xây dựng API của riêng mình hoặc đi sâu tìm hiểu tài liệu của một API có sẵn.

Điều kiện tiên quyết

Để nắm bắt tốt hướng dẫn này, bạn nên có một số kiến ​​thức cơ bản về dòng lệnh, biết các nguyên tắc cơ bản của JavaScript và cài đặt Node.js toàn cục.

REST và RESTful API là gì?

Representational State Transfer, hoặc REST, mô tả một kiểu kiến ​​trúc cho các dịch vụ web. REST bao gồm một tập hợp các tiêu chuẩn hoặc các ràng buộc để chia sẻ dữ liệu giữa các hệ thống khác nhau và các hệ thống cài đặt REST được gọi là RESTful. REST là một khái niệm trừu tượng, không phải là ngôn ngữ, framework hoặc kiểu phần mềm nào đó.

REST giống như một bộ sưu tập vinyl so với sử dụng dịch vụ phát nhạc trực tuyến. Với bộ sưu tập vinyl vật lý, mỗi bản ghi phải được nhân lên toàn bộ để chia sẻ và phân phối các bản sao. Tuy nhiên, với một dịch vụ phát trực tuyến, cùng một bản nhạc có thể được chia sẻ vĩnh viễn thông qua một tham chiếu đến dữ liệu như tiêu đề bài hát. Trong trường hợp này, phát nhạc trực tuyến là một dịch vụ RESTful và bộ sưu tập vinyl là một dịch vụ không RESTful.

API là viết tắt của Application Programming Interface, là giao diện cho phép các chương trình phần mềm giao tiếp với nhau. Một RESTful API đơn giản là một API tuân thủ các nguyên tắc và ràng buộc của REST. Trong một Web API, máy chủ nhận yêu cầu thông qua một URL endpoint và gửi về phản hồi, thường là dữ liệu ở định dạng chẳng hạn như JSON.

Các Nguyên tắc của REST

Sáu ràng buộc hướng dẫn xác định kiến ​​trúc REST, được nêu ở dưới đây.

  1. Uniform Interface: Giao diện của các thành phần phải giống nhau. Điều này có nghĩa là sử dụng URI tiêu chuẩn để xác định tài nguyên - nói cách khác, đường dẫn có thể được nhập vào thanh địa chỉ của trình duyệt.
  2. Client-Server: Có sự phân tách các mối liên hệ giữa server, nơi lưu trữ và xử lý dữ liệu và client, gửi yêu cầu và hiển thị phản hồi.
  3. Stateless Interactions: Tất cả các thông tin về mỗi yêu cầu được chứa trong mỗi yêu cầu riêng lẻ và không phụ thuộc vào trạng thái của session.
  4. Cacheable: Client và server có thể lưu cache tài nguyên.
  5. Layered System: Client có thể được kết nối với server cuối hoặc lớp trung gian chẳng hạn như một load-balancer.
  6. Code on Demand (Optional): Một client có thể tải về code, làm giảm khả năng hiển thị từ bên ngoài.

Yêu cầu và Phản hồi

Bạn đã quen với thực tế là tất cả các trang web đều có URL bắt đầu bằng http (hoặc https cho phiên bản bảo mật). HyperText Transfer Protocol, hay HTTP, là phương thức giao tiếp giữa client và server trên internet.

Chúng ta thấy nó rõ nhất trong thanh URL của trình duyệt, nhưng HTTP có thể được sử dụng không chỉ cho yêu cầu các trang web từ server. Khi bạn truy cập một URL trên web, bạn thực sự đang thực hiện một yêu cầu (request) GET trên tài nguyên cụ thể đó và trang web mà bạn thấy là nội dung của phản hồi (response). Chúng ta sẽ tìm hiểu về GET và các kiểu yêu cầu khác trong giây lát nữa.

HTTP hoạt động bằng cách mở kết nối TCP (Transmission Control Protocol) đến cổng server (80 cho http, 443 cho https) để thực hiện một yêu cầu và máy chủ lắng nghe và phản hồi với một trạng thái và body.

Một yêu cầu phải bao gồm một URL, phương thức, thông tin header và body.

Các phương thức yêu cầu

Có bốn phương thức HTTP chính, còn được gọi là động từ HTTP, thường được sử dụng để tương tác với web API. Các phương thức này xác định hành động sẽ được thực hiện với bất kỳ tài nguyên nào.

Các phương thức yêu cầu HTTP khá giống với mô hình của CRUD, viết tắt của Create, Update, Read, Delete. Mặc dù CRUD đề cập đến các hàm được sử dụng trong các thao tác cơ sở dữ liệu, chúng ta có thể áp dụng các nguyên tắc thiết kế đó cho các động từ HTTP trong RESTful API.

Hành động Phương thức yêu cầu Định nghĩa
Đọc GET Truy vấn tài nguyên
Tạo POST Tạo một tài nguyên mới
Cập nhật PUT Cập nhật tài nguyên hiện có
Xoá DELETE Xóa tài nguyên

GET là một hành động an toàn, chỉ đọc và sẽ không làm thay đổi trạng thái của server. Mỗi lần bạn nhập một URL trong trình duyệt của mình, chẳng hạn như https://www.google.com, bạn đang gửi một yêu cầu GET đến server của Google.

POST được sử dụng để tạo một tài nguyên mới. Một ví dụ quen thuộc về POST là đăng ký người dùng trên trang web hoặc ứng dụng. Sau khi gửi form, một yêu cầu POST với dữ liệu người dùng có thể được gửi đến server, sau đó sẽ ghi thông tin đó vào cơ sở dữ liệu.

PUT cập nhật tài nguyên hiện có, có thể được sử dụng để chỉnh sửa các cài đặt của người dùng có sẵn. Không giống như POST, PUTbình thường, có nghĩa là cùng một call có thể được thực hiện nhiều lần mà không tạo ra kết quả khác. Ví dụ, nếu bạn gửi cùng một yêu cầu POST để tạo người dùng mới trong cơ sở dữ liệu nhiều lần, nó sẽ tạo một người dùng mới có cùng dữ liệu cho mỗi yêu cầu bạn thực hiện. Tuy nhiên, sử dụng cùng một yêu cầu PUT trên cùng một người dùng sẽ liên tục tạo ra kết quả giống nhau.

DELETE, giống như tên gọi của nó, sẽ xóa một tài nguyên hiện có.

Code phản hồi

Khi một yêu cầu được gửi từ client đến server, server sẽ gửi trả phản hồi HTTP, bao gồm siêu dữ liệu về phản hồi được gọi là header, cũng như body. Phần đầu tiên và quan trọng nhất của một phản hồi là code trạng thái, nó cho biết một yêu cầu có thành công hay không, có lỗi hoặc phải thực hiện một hành động khác hay không.

Code phản hồi gặp nhiều nhất là 404, có nghĩa là Không tìm thấy. 404 là một phần của lớp code trạng thái 4xx, cho biết lỗi client. Có năm loại code trạng thái mà mỗi loại chứa một loạt các phản hồi khác nhau.

  • 1xx: Thông tin
  • 2xx: Thành công
  • 3xx: Chuyển hướng
  • 4xx: Lỗi client
  • 5xx: Lỗi server

Các phản hồi phổ biến khác mà bạn hay gặp là 301 Đã di chuyển vĩnh viễn, được sử dụng để chuyển hướng trang web sang URL mới và 500 Lỗi máy chủ nội bộ, đây là lỗi xuất hiện thường xuyên khi có sự cố bất ngờ xảy ra trên máy chủ khiến nó không thể thực hiện theo yêu cầu dự định

Liên quan đến RESTful API và các động từ HTTP tương ứng của chúng, tất cả các phản hồi phải nằm trong phạm vi 2xx.

Yêu cầu Phản hồi
GET 200 (OK)
POST 201 (Đã tạo)
PUT 200 (OK)
DELETE 200 (OK), 202 (Chấp nhận), hoặc 204 (Không có nội dung)

200 OK là phản hồi cho biết yêu cầu đã thành công. Nó được sử dụng như một phản hồi khi gửi yêu cầu GET hoặc PUT. POST sẽ trả về 201 đã được tạo để cho biết một tài nguyên mới đã được tạo và DELETE có một vài phản hồi có thể chấp nhận được, cho biết yêu cầu đã được chấp nhận (202) hoặc không có nội dung nào để trả về vì tài nguyên không còn tồn tại (204).

Chúng ta có thể kiểm tra code trạng thái của yêu cầu bằng cURL, là công cụ dòng lệnh được sử dụng để truyền dữ liệu thông qua URL. Với curl, theo sau là cờ -i hoặc --incoide, sẽ gửi yêu cầu GET tới một URL và hiển thị header cùng với body. Chúng ta có thể kiểm tra bằng cách mở chương trình dòng lệnh và thử chạy cURL với Google.

Server của Google sẽ phản hồi như sau.

Như chúng ta có thể thấy, yêu cầu curl trả về nhiều header và toàn bộ body HTML của phản hồi. Vì yêu cầu đã được thực hiện thành công, phần đầu tiên của phản hồi là code trạng thái 200, cùng với phiên bản HTTP (đây sẽ là HTTP/1.1 hoặc HTTP/2).

Vì yêu cầu cụ thể này trả về một trang web, content-type (loại MIME) được trả về là text/html. Trong RESTful API, bạn thường thấy application/json để cho biết phản hồi là JSON.

Thật thú vị, chúng ta có thể thấy một kiểu phản hồi khác bằng cách nhập một URL hơi khác. Thực hiện một curl trên Google mà không có www.

Google chuyển hướng google.com đến www.google.com và sử dụng code phản hồi 301 để chỉ ra rằng tài nguyên sẽ được chuyển hướng.

REST API Endpoint

Khi API được tạo trên một server, dữ liệu mà nó chứa có thể truy cập thông qua các endpoint. Một endpoint là URL của yêu cầu có thể chấp nhận và xử lý yêu cầu GET, POST, PUT hoặc DELETE.

Một API URL sẽ bao gồm root, path và có thể có chuỗi truy vấn.

  • Root ví dụ như https://api.example.com hoặc https://api.example.com/v2: Gốc của API, có thể bao gồm giao thức, tên miền và phiên bản.
  • Path, ví dụ như, /users/ hoặc /users/5: Vị trí riêng biệt của một tài nguyên cụ thể.
  • Query Parameters (không bắt buộc) ví dụ như, ?location=chicago&age=29: Các cặp giá trị khóa tùy chọn được sử dụng để sắp xếp, lọc và phân trang.
    Chúng ta có thể kết hợp tất cả chúng lại với nhau để cài đặt một thứ gì đó như ví dụ bên dưới, sẽ trả về danh sách tất cả người dùng và sử dụng tham số truy vấn limit để lọc các câu trả lời chỉ bao gồm mười kết quả.

https://api.example.com/users?limit=10

Nói chung, khi mọi người nói đến API là RESTful API, họ đang đề cập đến quy ước đặt tên để xây dựng các API URL endpoint. Một vài quy ước quan trọng cho RESTful API tiêu chuẩn như sau:

  • Paths should be plural: ví dụ, để có được người dùng có id là 5, chúng ta sẽ sử dụng /users/5 chứ không phải là /user/5.
  • Endpoint không được hiển thị phần mở rộng tập tin: Mặc dù API thường trả về JSON, nhưng URL không nên kết thúc bằng .json.
  • Endpoint nên sử dụng danh từ, không phải động từ: Các từ như thêmxóa không xuất hiện trong một REST URL. Để thêm một người dùng mới, bạn chỉ cần gửi một yêu cầu POST đến /users, không phải kiểu như /users/add. API nên được phát triển để xử lý nhiều loại yêu cầu cho cùng một URL.
  • Path cần phân biệt chữ hoa chữ thường và nên được viết bằng chữ thường với dấu gạch ngang không phải là dấu gạch dưới.

Tất cả các quy ước này đều là hướng dẫn, vì không có tiêu chuẩn REST nghiêm ngặt nào cần phải tuân thủ. Tuy nhiên, sử dụng các nguyên tắc này sẽ giúp API của bạn nhất quán, quen thuộc và dễ đọc cũng như dễ hiểu.

Tổng kết

Trong bài viết này, chúng ta đã tìm hiểu về REST và RESTful API là gì, các phương thức yêu cầu HTTP và code phản hồi hoạt động như thế nào, cấu trúc của một API URL và các quy ước RESTful API phổ biến. Trong hướng dẫn tiếp theo, chúng ta sẽ tìm hiểu cách sử dụng tất cả lý thuyết này để thiết lập một server Express với Node.js và xây dựng API của riêng chúng ta.

Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.