Một ứng dụng web, RESTful hay không, thường không chỉ đơn giản là một dịch vụ dữ liệu; nó phơi bày các tài nguyên khác nhau và cung cấp một số hành vi, và vì vậy nó có trạng thái; một phân biệt được thực hiện giữa trạng thái tài nguyên (độc lập với máy khách, được quản lý bởi ứng dụng) và trạng thái ứng dụng , là trạng thái dành riêng cho máy khách. Một ứng dụng không trạng thái không lưu trữ trạng thái ứng dụng (dành riêng cho khách hàng); thay vào đó, nó cho phép khách hàng chịu trách nhiệm về nó và cung cấp một API cho phép chuyển trạng thái (ứng dụng) qua lại (do đó " S tate T ransfer" trong RE ST). Từ góc nhìn của khách hàng, ứng dụng web là một máy trạng thái, nằm sau API cho phép tương tác, nhưng một phần trạng thái được cung cấp dưới dạng thông tin theo ngữ cảnh của khách hàng, để bổ sung các yêu cầu.
Bây giờ, trong khi nghiên cứu REST, bạn có thể đã tình cờ phát hiện ra một thứ gọi là Mô hình trưởng thành của Richardson- nó mô tả "sự trưởng thành" của API ứng dụng web (phát triển qua nhiều năm), nhưng nó hữu ích đối với chúng tôi như một loại tài liệu tham khảo đặt mọi thứ vào ngữ cảnh. Trong mô hình này, tất cả các mức trưởng thành, ngoại trừ mức cuối cùng, về cơ bản đều cung cấp các API tạo điều kiện cho các RPC qua HTTP. Theo kiểu thiết kế API này, HTTP được sử dụng như một cơ chế vận chuyển, nhưng giao tiếp thực tế xảy ra qua các giao thức tùy chỉnh, do đó các hệ thống tương tác (máy khách và ứng dụng) dựa vào cái gọi là "thông tin ngoài băng tần" để giao tiếp (trong điều này bối cảnh, điều này chỉ có nghĩa là các hệ thống này giao tiếp bằng cách sử dụng một số tiêu chuẩn tùy chỉnh thay vì tận dụng siêu văn bản / hypermedia và, giả sử, giao thức HTTP hiện có). Vì vậy, những gì thúc đẩy chuyển trạng thái và chuyển trạng thái ("động cơ của trạng thái ứng dụng") không phải là hypermedia trong trường hợp này.
Mức trưởng thành cuối cùng đưa ra ràng buộc HATEOAS và chỉ sau đó API mới trở thành RESTful. Máy khách khởi tạo sự tương tác thông qua URI ban đầu; máy chủ phản hồi với biểu diễn trạng thái ứng dụng dựa trên hypermedia phù hợp (có thể khác nhau giữa các thiết bị hoặc máy khách hoặc do các điều kiện khác nhau - do đó " Re trình bày" trong RE ST), bao gồm các hành động tự mô tả cho phép máy khách bắt đầu quá trình chuyển đổi trạng thái tiếp theo (vì vậy hypermedia hiện là thứ trực tiếp hỗ trợ và thúc đẩy trạng thái ứng dụng).
Tôi có thể chọn tuyên bố rằng "Trạng thái ứng dụng là ứng dụng khách cụ thể" không. Đó là cách tôi hiểu nó. [...] Nó hoàn toàn có liên quan đến tính khả dụng của tài nguyên phía máy chủ, không có gì (rõ ràng mà tôi có thể thấy) liên quan đến trạng thái máy khách ...
Trước tiên hãy để tôi chắc chắn rằng chúng ta đang ở trên cùng một trang. Đây không phải là trạng thái máy khách (như trong trạng thái bên trong của chính máy khách), mà là trạng thái của ứng dụng web dành riêng cho một máy khách cụ thể.
Ví dụ bạn đề cập không thực sự minh họa tốt cho nó, nhưng danh sách các liên kết được trả về về cơ bản được tạo động trên máy chủ và thể hiện các chuyển đổi trạng thái hiện có và do đó, nó mã hóa trạng thái ứng dụng hiện tại (cho ứng dụng khách cụ thể đó). Lưu ý rằng bạn có thể chọn chuyển các bit thông tin liên quan đến trạng thái khác (theo cả hai hướng) nếu ứng dụng của bạn yêu cầu (vì vậy bạn không bị giới hạn đối với siêu dữ liệu chuyển đổi trạng thái), nhưng hạn chế là không bao giờ nhớ bất kỳ dữ liệu cụ thể nào của khách hàng trên Máy chủ, vì điều đó làm tổn thương khả năng bán được. Cũng lưu ý rằng trạng thái này không phải hoàn thành (không nhất thiết phải hoàn toàn có ý nghĩa khi bạn nhìn riêng lẻ), nhưng nó phải đủ để bên nhận đưa ra quyết định và thực hiện logic dựa trên nó và không có gì khác (vì vậy,
HATEOAS tận dụng giao diện thống nhất (các tiêu chuẩn và định dạng trao đổi dữ liệu chung) để tách rời các máy khách và máy chủ để ở phía máy chủ, chúng có thể xáo trộn các thứ xung quanh đằng sau "hợp đồng" được xác định bởi loại hypermedia, nhưng cũng vì giao tiếp dựa trên thông tin băng tần (giao thức tùy chỉnh) thường không tận dụng cơ sở hạ tầng mạng theo cách mà REST nhắm đến. (Xem phần thảo luận bên dưới.)
Trong ví dụ của bạn, máy khách sẽ không dựa trên logic của nó trên URI, mà dựa trên siêu dữ liệu (hoặc chú thích), như thuộc tính "rel". Ví dụ: trình duyệt không quan tâm đến các URI trong liên kết, nó chỉ cần biết đó là loại liên kết nào (liên kết có thể nhấp, một hình thức mà bạn có thể tạo URI, tham chiếu biểu định kiểu, v.v.)
REST trong bối cảnh
Thật không may, REST đã trở thành một từ thông dụng và mọi người đang nói về cách trở thành RESTful, nhưng toàn bộ bối cảnh của REST bị thiếu và bạn không thể hiểu được phong cách kiến trúc REST mà không hiểu ngữ cảnh này (vấn đề mà REST thực sự là gì cố gắng giải quyết).
REST là một khái quát của kiến trúc đằng sau Web . Đối với hầu hết chúng ta, Web là một nền tảng. Nhưng đối với những người đã phát triển REST, WWW là một ứng dụng , có một bộ yêu cầu nhất định, chạy trên một mạng toàn cầu. Vì vậy, REST có nghĩa là cho các hệ thống giống như Web trong một số khía cạnh quan trọng, cần phải đáp ứng một tập các thuộc tính nhất định.
Đây là những hệ thống mạng quy mô lớn tồn tại lâu dài (nghĩ nhiều thập kỷ). Đây là các hệ thống vượt qua các ranh giới tổ chức (ví dụ: các công ty hợp tác) hoặc các ranh giới giữa các chi nhánh khác nhau trong một tổ chức lớn (như các bộ phận khác nhau và thậm chí các nhóm). Mặc dù có sự hợp tác, các thực thể liên quan chủ yếu vận hành (làm việc, phát triển và triển khai phần mềm) theo cách riêng của họ, theo tốc độ của riêng họ, với mối quan tâm bảo mật của riêng họ và tất cả họ đều sử dụng các thiết bị, hệ điều hành khác nhau, v.v. cần truy cập và chia sẻ tài liệu tham khảo đến các tài nguyên của nhau (tài liệu, dịch vụ, dữ liệu), trong khi có thể phát triển độc lập và tăng dần, mà không cần phải phối hợp rộng rãi (heck, thật khó để mọi người thực hiện triển khai phối hợp ngay cả trong cùng một tổ chức).
Những người cung cấp dịch vụ cần có khả năng thực hiện những việc như phát triển các phiên bản dịch vụ, thêm nút hoặc xáo trộn dữ liệu xung quanh với hiệu quả tối thiểu đối với khách hàng. Họ cần phải mở rộng quy mô. Khách hàng (có thể tự là dịch vụ) cần tiếp tục hoạt động mặc dù tất cả hoạt động này ở phía máy chủ. Các hệ thống có thể sẽ được sử dụng theo những cách không lường trước được trong tương lai. Các tài nguyên họ truy cập và trao đổi có thể có nhiều loại khác nhau và được nhận ra (được mã hóa, đánh máy, đại diện, cấu trúc) trong nội bộ (bởi các nhà cung cấp dịch vụ) theo nhiều cách khác nhau, nhưng ngay cả đối với toàn bộ hệ thống / mạng, một cách nhất quán tài nguyên truy cập và dữ liệu cấu trúc và phản hồi là bắt buộc (giao diện thống nhất).
REST tính đến tất cả những điều này, và rất nhiều xem xét các thuộc tính của mạng. Nó có nghĩa là để giải quyết các nhu cầu của các ứng dụng, ở mức độ cao (trong lĩnh vực kinh doanh của riêng họ), tương tự về các yêu cầu và ràng buộc đối với những gì được nêu ở trên (hoặc mong muốn).
Và nó có, nhưng nó không phải là thuốc chữa bách bệnh. Có chi phí và sự đánh đổi. Nó áp đặt một phong cách giao tiếp nhất định, và có một hiệu suất thành công. Bạn luôn truyền dữ liệu theo cách phân loại thô, thường là cùng một dữ liệu lặp đi lặp lại, theo định dạng chung chung (và do đó có thể không hiệu quả nhất cho dịch vụ của bạn), với một loạt siêu dữ liệu, thường xuyên qua các nút mạng trung gian ( do đó, tất cả các bộ nhớ đệm trên Web - nó giảm thiểu việc gửi dữ liệu qua lại, giữ máy khách tránh xa dịch vụ khi có thể). Hiệu suất nhận thức của người dùng rất quan trọng, điều này ảnh hưởng đến cách bạn viết ứng dụng khách (đây là lý do tại sao trình duyệt bắt đầu hiển thị trang trước khi mọi thứ được tải xuống hoặc sẵn sàng). Nhưng bạn vui vẻ trả chi phí đó để có thể xây dựng một hệ thống với các thuộc tính được mô tả ở trên.
Ngược lại, nếu bạn đang xây dựng một hệ thống có các yêu cầu / ràng buộc khác nhau, chi phí có thể không đáng.