Thực hư RESTful API, REST API và những "uẩn khúc" liên quan

Hello anh em lại là culi đây ! Như anh em đồng đạo chắc hẳn ai cũng đã từng nghe mấy từ "API, Restful API, Rest API" nhìn nó chỉ khác nhau đôi chút vậy những thứ mình vừa nói là cái mẹ gì ? (Anh em nào đã biết rồi cũng chịu khó đọc lại nha )



5s quảng cáo nhớ LIKE fanpage để theo dõi bài viết mới : 

https://www.facebook.com/culicoder/

Giải thích thuật ngữ ?

• API : application program interface (quá quen thuộc tạm không nói :v)
• REST (Representational State Transfer ) : cụm từ này được "tạo" ra từ luận văn tiến sĩ Roy Thomas Fielding (đồng sáng lập giao thức HTTP) năm 2000 , trong đó trình bày chi tiết về các ràng buộc, quy ước cũng như cách thức thực hiện với hệ thống để có được một hệ thống REST. Nói cách khác, đây là một kiểu kiến trúc thiết kế API thông dụng với các giao thức HTTP phổ biến : GET, POST, PUT,DELETE,...
• RESTful (-ful là tiếp vị ngữ giống như beauty và beautiful) : nôm na đây là một chuẩn thiết kế API một thuật ngữ khác của REST , tuy nhiên anh em có thể xem REST và RESTful là một , khỏi lăng tăng làm gì cho mệt =)) .

Các chuẩn hay ràng buộc của một API cần đảm bảo ?

• Client-server architecture : hệ thống hoạt động theo mô hình client-server . Cô client gửi "tin nhắn" còn anh server lúc nào cũng lắng nghe những "tin nhắn" từ cô client để luôn đáp ứng yêu cầu và trả lời chính xác những gì cô client muốn . Bên cạnh đó anh server có thể làm một hay nhiều "task" cùng lúc để có thể hoàn thành những gì cô client yêu cầu.
• Statelessness: Phi trạng thái 2 , cả phía client và server đều không lưu trạng thái của nhau . Ở bất cứ tin nhắn nào cũng đều có thông tin để 2 bên nhận ra nhau :v.
• Cacheability : nói ngắn gọn là có khả năng cache, những "câu trả lời" (response) từ phía server có thể lưu ở cache để giảm tải việc goị lại khi không cần thiết=> "mệt" lắm.
• Layered system : trong hệ thống chia tách các thành phần hệ thống theo từng lớp, mỗi lớp chỉ sử dụng lớp ở dưới nó và giao tiếp với lớp ở ngay trên nó mà thôi. Điều này giúp giảm độ phức tạp của hệ thống, giúp các thành phần tách biệt nhau và rõ ràng hơn => dể bảo trì và mở rộng
• Code on demand (optional) : máy chủ có thể gửi một "action" hay một custom function đến client thực thi , anh em có thể tham khảo Client-side script
• Uniform interface : đây là điều tiên quyết khi thiết kế REST API interface phải được thiết kế rõ ràng rành mạch và theo "chuẩn" cụ thể để thuận tiện cho việc quản lý tài nguyên:
• Resource identification in requests
• Resource manipulation through representationsSelf-descriptive messages
• Hypermedia as the engine of application state (HATEOAS)

Vậy RESTful API có lợi ích gì không mà thiết kế chi cho cực vậy ? Dĩ nhiên có rồi 

• Hiệu năng: các thành phần đảm bảo được việc giao tiếp theo đúng một quy ước giúp hệ thống có thể vận hành tốt hơn.

• Tính khả biến: với các hệ thống cần thay đổi các tài nguyên liên tục, sử dụng REST với việc tạo request đơn giản sẽ giúp mọi chuyển trở nên đơn giản hơn.

• Tính mở rộng: các hệ thống REST có khả năng mở rộng rất cao nhờ sự tách biệt giữa các thành phần và các quy ước giao tiếp được quy định sẵn.

• Tính linh hoạt: việc chuẩn hoá interface giúp hệ thống trở nên linh hoạt hơn, có thể sử dụng cho cho nhiều nền tảng khác nhau, mobile, web,...

• Trong sáng: trong giao tiếp giữa các thành phần, các request trở nên rất rõ ràng, dễ hiểu an toàn và tách bạch 

• Tính tin cậy: khó để xảy ra lỗi trong giao tiếp giữa các thành phần gây sụp đổ hệ thống.

Sách vở thì bảo thế nhưng với góc nhìn của mình nhờ có RESTful API mà client-side dễ thở hơn, không cần xử lý logic nặng nề, cũng chả cần cài framework hay thư viện gì cao siêu để xử lý mọi thứ đều có thể nhờ "anh" server đẹp trai và mạnh mẽ xử lý và quăng một "cục" JSON mà xài cho sướng.

Anh em cần nên có những "chiêu" sau khi xây dựng REST API ?

• Trời , đã tốn công thiết kế một kiến trúc để có API ổn thì anh em nên có một HTTP method tương ứng cho hợp lý . Chẳng hạn muốn lấy dữ liệu thì GET , muốn thêm thì POST , muốn cập nhật thì PUT ,... chứ đừng có lấy dữ liệu mà POST lên thì quê lắm =))

• Vui lòng sử dụng kiểu dữ liệu JSON để client và server dễ nói chuyện và "parse".

• Request nào cũng nên cho "nguời ta" một cái HTTP Status Code để người anh em phía client còn biết mà xử lý và đừng quên lỗi thì nên cho người ta miêu tả rõ ràng luôn .

• Đã thiết kế API và thông báo lỗi cho client tốt thì đừng quên viết hoặc sử dụng một Monitor Service để theo dõi "bệnh tình" của API (nếu có).

• Nếu hệ thống có nhiều user thì tốt nhất nên thêm Rate limiting để tránh trường hợp bị "xài" quá nhiều mà thành ra "hao gầy" vì tài nguyên server có hạn.

• À còn nữa lúc query hay lấy dữ liệu thì nhớ phân trang , còn phân trang như nào thì phải tuỳ cách anh em rồi :D . Nghiêm cách "SELECT * from TABLE" hay" yourModel.find({})" và trả nguyên cục dữ liệu bự về client mới phân trang thì khá là cục súc.

• Những request quan trọng nên thiết kế middleware (bên NodeJS gọi thế không biết bên công nghệ anh em đang dùng gọi là gì ?) middleware phải chất lượng và bảo mật chứ đừng để bọn nó request 1 cái sập cả hệ thống hoặc tự nhiên query phát lấy gọn data , tai hại hơn là user có quyền như admin và....................... toang !!!

Thế đấy, thiết kế một API "hoàn thiện" nào có dễ đâu , anh em có đụng vô thì nhớ cẩn thận và tỉ mỉ kẻo "vỡ mồm". Chém gió thế thôi có gì anh em góp ý để Culi cải thiện bài viết cũng như trao đổi kiến thức nhé ? À quên đã làm API anh em có bao giờ mắc lỗi hoặc một thiếu xót khiến "hệ thống" ăn hành lần nào chưa ? Chia sẻ với mình và mọi người dưới phần comment nhé !

Còn tiếp, đói bụng quá ăn cơm cái vài bữa nữa viết tiếp phần 2 anh em nhé !

Chúc anh em coding vui vẻ !


Nhớ like fanpage để theo dõi bài mới nè :

https://www.facebook.com/culicoder/