REST (Representational State Transfer) là 1 phong cách kiến trúc hệ thống hypermedia (phương tiện thông tin phi tuyến) phân tán.
Hiện nay, REST là lựa chọn phổ biến nhất để phát triển API, REST API hoặc RESTful API được thiết kế để tận dụng các giao thức hiện có. Mặc dù REST có thể được sử dụng trên hầu hết các giao thức, nhưng nó thường tận dụng lợi thế của HTTP khi được sử dụng cho các API Web. Điều này có nghĩa là các nhà phát triển không cần cài đặt thư viện hoặc phần mềm bổ sung để tận dụng REST API.
Theo định nghĩa của Tiến sĩ Dr. Roy Fielding trong Luận án Tiến sĩ năm 2000 của ông, REST cung cấp một lớp rất linh hoạt. Vì dữ liệu không bị ràng buộc với các phương thức và tài nguyên, nên REST có khả năng xử lý nhiều loại lệnh gọi, trả về các định dạng dữ liệu khác nhau và thậm chí thay đổi cấu trúc với việc triển khai chính xác hypermedia.
Như bạn có thể thấy trong bảng trên, mỗi loại API cung cấp những điểm mạnh và điểm yếu khác nhau. Tuy nhiên, REST cung cấp một sự tự do và tính linh hoạt đáng kể, cho phép bạn xây dựng một API đáp ứng nhu cầu của mình đồng thời đáp ứng nhu cầu của những khách hàng rất đa dạng.
Không giống như SOAP, REST không bị ràng buộc với XML mà thay vào đó có thể trả về XML, JSON, YAML hoặc bất kỳ định dạng nào khác tùy thuộc vào những gì khách hàng yêu cầu. Và không giống như RPC, người dùng không bắt buộc phải biết tên thủ tục hoặc các thông số cụ thể theo một thứ tự cụ thể.
Nhưng bạn cũng mất khả năng duy trì trạng thái trong REST, chẳng hạn như trong các phiên làm việc và có thể khó sử dụng hơn đối với các nhà phát triển mới hơn. Điều quan trọng hơn nữa là phải hiểu điều gì là REST và tại sao những ràng buộc này tồn tại trước khi xây dựng API của bạn. Rốt cuộc, nếu bạn không hiểu tại sao một thứ gì đó lại được thiết kế theo cách của nó, bạn có nhiều khả năng bỏ qua một số yếu tố nhất định và đi chệch hướng, đôi khi cản trở nỗ lực phát triển hệ thống của bạn mà không hề nhận ra.
Đáng ngạc nhiên là trong khi hầu hết các API tuyên bố là RESTful, chúng không đáp ứng được các yêu cầu và ràng buộc được khẳng định bởi Tiến sĩ Dr. Roy Fielding. Một trong những hạn chế thường bị bỏ qua nhất của REST là việc sử dụng Hypermedia như là động cơ của trạng thái ứng dụng (HATEOAS – viết tắt của “Hypermedia as the Engine of Application State”)
Có 6 ràng buộc chính đối với REST mà bạn nên biết khi quyết định xem đây có phải là loại API phù hợp với hệ thống hay không.
Nói cách khác, tôi có thể thực hiện các thay đổi đối với ứng dụng phía client của mình mà không ảnh hưởng đến cấu trúc dữ liệu hoặc thiết kế cơ sở dữ liệu trên server. Đồng thời, tôi có thể sửa đổi cơ sở dữ liệu hoặc thực hiện các thay đổi đối với ứng dụng server của mình mà không ảnh hưởng đến ứng dụng trên client. Điều này tạo ra sự tách biệt về chức năng của hệ thống, cho phép mỗi ứng dụng phát triển và mở rộng quy mô một cách độc lập và cho phép các tổ chức phát triển hệ thống một cách nhanh chóng và hiệu quả.
Các API REST sẽ không lưu trữ trạng thái, có nghĩa là tất cả các lệnh gọi đến server đều được thực hiện độc lập và mỗi lệnh gọi chứa tất cả thông tin dữ liệu cần thiết để hoàn thành lệnh gọi đó. Các API REST không nên dựa vào dữ liệu được lưu trữ trên server như các phiên làm việc để xác định phải làm gì với một lệnh gọi, mà chỉ dựa vào dữ liệu được cung cấp trong chính lệnh gọi đó.
Điều này có thể gây nhầm lẫn, đặc biệt là khi bạn nghe về việc sử dụng dữ liệu cung cấp trong lệnh gọi làm trạng thái của ứng dụng (Chờ đã – tôi nghĩ REST là không trạng thái?) .. Đừng lo lắng, chúng ta sẽ nói về điều này sau, nhưng điều quan trọng ở đây là phiên hoặc thông tin nhận dạng không được lưu trữ trên máy chủ. Thay vào đó, mỗi lệnh gọi có dữ liệu cần thiết, chẳng hạn như khóa API, mã thông báo truy cập, ID người dùng, v.v. Điều này cũng giúp tăng độ tin cậy của API bằng cách có tất cả dữ liệu cần thiết để thực hiện cuộc gọi, thay vì dựa vào một loạt lệnh gọi với trạng thái server để tạo một đối tượng, điều này có thể dẫn đến lỗi một phần. Thay vào đó, để giảm các yêu cầu bộ nhớ và giữ cho ứng dụng có khả năng mở rộng càng nhiều càng tốt, API RESTful yêu cầu trạng thái được lưu trữ trên máy khách — không phải trên máy chủ.
Cache: Client lưu trữ dữ liệu vào cache.
Bởi vì API REST không lưu trữ trạng thái đều này có thể làm tăng số lượng các yêu cầu xử lý cuộc gọi đến và đi, một API REST nên được thiết kế để khuyến khích client lưu trữ dữ liệu có thể lưu vào cache. Điều này có nghĩa là khi dữ liệu có thể lưu vào cache, phản hồi từ API REST phải chỉ ra rằng dữ liệu có thể được lưu trữ đến một thời điểm nhất định (hết hạn tại thời 1 điểm trong tương lai) hoặc trong trường hợp dữ liệu cần ở thời gian thực, phản hồi sẽ chỉ ra rằng dữ liệu không được lưu vào cache trên client.
Bằng cách này, bạn sẽ không chỉ giảm đáng kể số lượng tương tác với API của mình, giảm mức sử dụng máy chủ nội bộ mà còn cung cấp cho người dùng API của bạn các công cụ cần thiết để cung cấp các ứng dụng nhanh nhất và hiệu quả nhất có thể.
Hãy nhớ rằng cache được thực hiện ở phía máy khách. Mặc dù bạn có thể lưu vào cache một số dữ liệu trong kiến trúc của mình để đạt được hiệu suất tổng thể, nhưng mục đích là hướng dẫn client cách tiến hành và liệu client có thể lưu trữ dữ liệu vào cache hay không.
Uniform Interface: Giao diện thống nhất (e.g HTTP method and content-type is JSON or XML)
Chìa khóa để tách client khỏi server là có một giao diện đồng nhất cho phép ứng dụng phát triển độc lập mà không cần phải phát triển các dịch vụ hoặc mô hình và hành động của ứng dụng đi theo chính lớp API đó. Giao diện thống nhất cho phép client nói chuyện với server bằng một ngôn ngữ duy nhất, độc lập với phần phụ trợ kiến trúc của cả hai. Giao diện này phải cung cấp phương tiện giao tiếp chuẩn hóa, không thay đổi giữa client và server, chẳng hạn như sử dụng HTTP với tài nguyên URI, CRUD (Create, Read, Update, Delete) và JSON.
Tuy nhiên, để cung cấp một giao diện thực sự thống nhất, Dr. Roy Fielding đã xác định bốn ràng buộc giao diện bổ sung:
Khái niệm HATEOAS khá khó hiểu bởi Dr. Roy Fielding không giải thích gì trong luận văn của mình, ông chỉ nói rằng nó là thành phần quan trọng để có một giao diện thống nhất.
Như tên của nó, một hệ thống phân lớp là một hệ thống bao gồm các lớp, với mỗi lớp có một chức năng và trách nhiệm cụ thể. Nếu chúng ta nghĩ về khung Bộ điều khiển Chế độ xem Mô hình, mỗi lớp có trách nhiệm riêng của mình, với các mô hình bao gồm cách dữ liệu sẽ được hình thành, bộ điều khiển tập trung vào các hành động đến và chế độ xem tập trung vào đầu ra. Mỗi lớp riêng biệt nhưng cũng tương tác với lớp khác.
Trong REST, nguyên tắc tương tự cũng đúng, với các lớp khác nhau của kiến trúc làm việc cùng nhau để xây dựng hệ thống phân cấp giúp tạo ra một ứng dụng module và có thể mở rộng hơn. Ví dụ: một hệ thống phân lớp cho phép cân bằng tải và định tuyến. Hệ thống phân lớp cũng cho phép bạn đóng gói các hệ thống và chuyển chức năng ít được truy cập hơn sang một trung gian khác, đồng thời tách các thành phần module thường được sử dụng hơn khỏi chúng. Hệ thống phân lớp cũng cho phép bạn tự do di chuyển hệ thống vào và ra khỏi kiến trúc của bạn khi công nghệ và dịch vụ phát triển, tăng tính linh hoạt và tuổi thọ miễn là bạn giữ cho các module khác nhau được kết nối lỏng lẻo nhất có thể.
Có những lợi ích bảo mật đáng kể khi có một hệ thống phân lớp vì nó cho phép bạn ngăn chặn các cuộc tấn công ở lớp proxy hoặc trong các lớp khác, ngăn chúng xâm nhập vào kiến trúc máy chủ thực tế của bạn. Bằng cách sử dụng hệ thống phân lớp với proxy hoặc tạo một điểm truy cập duy nhất, bạn có thể giữ các thành phần quan trọng và dễ bị tấn công hơn trong kiến trúc của mình sau tường lửa, ngăn chặn sự tương tác trực tiếp với chúng bởi ứng dụng khách.
Hãy nhớ rằng bảo mật không chỉ dựa trên một giải pháp là “dừng tất cả”, mà dựa trên việc có nhiều lớp dù biết rằng các cách kiểm tra bảo mật nhất định có thể không thành công hoặc bị bỏ qua. Như vậy, càng có nhiều giải pháp triển khai bảo mật vào hệ thống của mình, bạn càng có nhiều khả năng ngăn chặn được các cuộc tấn công gây hại.
Có lẽ ít được biết đến nhất trong số sáu ràng buộc và cũng là ràng buộc tùy chọn duy nhất, Mã theo yêu cầu cho phép code hoặc ứng dụng nhỏ được truyền qua API để sử dụng trong ứng dụng. Về bản chất, nó tạo ra một ứng dụng thông minh không còn phụ thuộc hoàn toàn vào cấu trúc mã của chính nó.
You need to login in order to like this post: click here
YOU MIGHT ALSO LIKE
SUBSCRIBE TO OUR NEWSLETTER
