Điểm nào với HATEOAS ở phía khách hàng?

Như tôi hiện đang hiểu, HATEOAS về cơ bản là tất cả về việc gửi cùng với mỗi liên kết phản hồi với thông tin về những việc cần làm tiếp theo. Một ví dụ đơn giản có thể dễ dàng tìm thấy trên internet: một hệ thống ngân hàng cùng với tài nguyên tài khoản. Ví dụ cho thấy phản hồi này sau khi yêu cầu NHẬN tài nguyên tài khoản

GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK 
<?xml version="1.0"?> 
<account> 
    <account_number>12345</account_number> 
    <balance currency="usd">100.00</balance> 
    <link rel="deposit" href="/account/12345/deposit" /> 
    <link rel="withdraw" href="/account/12345/withdraw" /> 
    <link rel="transfer" href="/account/12345/transfer" /> 
    <link rel="close" href="/account/12345/close" /> 
</account>

Cùng với dữ liệu có các liên kết cho biết những gì có thể được thực hiện tiếp theo. Nếu số dư là âm chúng ta có

GET /account/12345 HTTP/1.1 HTTP/1.1 200 OK 
<?xml version="1.0"?> 
<account> 
    <account_number>12345</account_number> 
    <balance currency="usd">-25.00</balance> 
    <link rel="deposit" href="/account/12345/deposit" /> 
</account>

Vì vậy, chúng tôi chỉ có thể gửi tiền. Điều đó hoàn toàn tốt, nếu chúng ta đang sử dụng Fiddler hoặc thực hiện các yêu cầu với trình duyệt, chúng ta có thể dễ dàng thấy những gì có thể được thực hiện. Loại thông tin này hữu ích sau đó để chúng tôi khám phá các khả năng của API và máy chủ được tách rời khỏi máy khách.

Tuy nhiên, vấn đề là khi chúng tôi xây dựng một ứng dụng khách, như một SPA với Javascript, hoặc một ứng dụng Android hoặc nhiều thứ khác, tôi không thể thấy HATEOAS tiếp tục liên quan như thế nào. Ý tôi là như sau: khi tôi mã hóa SPA bằng javascript, tôi phải biết những gì có thể được thực hiện trong API để viết mã.

Vì vậy, tôi cần biết các tài nguyên, các phương thức được hỗ trợ, những gì họ mong muốn nhận được và những gì họ trả lại để viết các cuộc gọi ajax đến máy chủ và thậm chí để xây dựng giao diện người dùng. Khi tôi xây dựng giao diện người dùng, tôi phải biết rằng sau khi yêu cầu tài khoản, người ta có thể gửi tiền vào tài khoản đó, hoặc tôi sẽ không thể cung cấp tùy chọn này trên giao diện người dùng. Ngoài ra, tôi sẽ cần biết URI để thực hiện gửi tiền để xây dựng cuộc gọi ajax.

Ý tôi là, khi chúng tôi yêu cầu API, các liên kết cho phép chúng tôi khám phá và sử dụng API tốt hơn, nhưng khi chúng tôi xây dựng một ứng dụng khách, ứng dụng chúng tôi đang xây dựng sẽ không chỉ nhìn vào các liên kết và sau đó tự hiển thị UI chính xác và thực hiện các cuộc gọi ajax đúng.

Vậy, HATEOAS quan trọng như thế nào đối với khách hàng? Tại sao chúng ta bận tâm với HATEOAS?

ứng dụng chúng tôi đang xây dựng sẽ không chỉ đơn giản là nhìn vào các liên kết và sau đó tự nó hiển thị giao diện người dùng chính xác và thực hiện các cuộc gọi ajax đúng

Trên thực tế, đây chính xác là những gì HATEOAS sẽ cung cấp cho UI. Không phải những gì có thể, nhưng khi nó có thể. Một HATEOAS chính thức như HAL , như câu hỏi nêu ra, đưa ra các liên kết chỉ ra những gì có thể. Nhưng khi các liên kết đó xuất hiện phụ thuộc vào trạng thái của ứng dụng. Vì vậy, các liên kết có thể thay đổi trên tài nguyên theo thời gian (dựa trên các hành động đã được thực hiện).

Điều này cho phép chúng ta xây dựng một giao diện người dùng có chứa tất cả các khả năng quốc gia, nhưng không được quan tâm khi những quốc gia trở thành hoạt động. Ví dụ: sự hiện diện của rel="deposit"giao diện người dùng có thể trực tiếp báo cho UI khi nào có thể hiển thị make depositbiểu mẫu. Sau đó cho phép người dùng nhập một giá trị và gửi bằng liên kết.

Như tôi hiện đang hiểu, HATEOAS về cơ bản là tất cả về việc gửi cùng với mỗi liên kết phản hồi với thông tin về những việc cần làm tiếp theo

HATEOAS không chỉ là liên kết. Nó là "siêu phương tiện" như là công cụ của trạng thái ứng dụng.

Những gì bị bỏ lỡ trong mô tả của bạn là loại nội dung, định nghĩa chính thức của siêu phương tiện được truyền giữa máy khách và máy chủ.

HTML là một ví dụ về siêu phương tiện và là một ví dụ về lý do tại sao HATEOS hoạt động. Bản thân trang HTML là công cụ cho phép khách hàng (tức là người dùng) di chuyển qua trang web. Một trình duyệt chỉ có khả năng hiển thị HTML hiện diện cho người dùng một trang web có thể điều hướng hoàn toàn. Nó không chỉ đơn giản là nó chuyển các liên kết đến các trang khác mà nó chuyển chúng theo một cách có ý nghĩa mang lại bối cảnh cho các liên kết và theo cách thức cho phép trình duyệt xây dựng một trang web có thể điều hướng.

Và quan trọng nhất là trình duyệt có thể làm điều này với sự hiểu biết trước về trang web. Trình duyệt chỉ biết HTTP và HTML. Dựa trên sự hiểu biết đơn giản đó, nó có thể trình bày Thời báo New York cho người dùng để điều hướng qua.

Điều này giữ ngay cả khi "người dùng" là một chương trình máy tính khác. Các siêu phương tiện nên xác định bối cảnh của điều hướng.

Bạn không phải xây dựng một giao diện được tạo động. Mặc dù nó có thể tốt nhưng nó không bắt buộc. Nếu bạn không thể xây dựng một giao diện động, chỉ cần sử dụng các liên kết và bạn đã hoàn thành. Nhược điểm là bạn lại khó liên kết với phụ trợ và sẽ gặp sự cố nếu có gì đó thay đổi.

Sử dụng bố cục động có thể khá đơn giản btw:

links.forEach(function(link) {

  switch(link.rel) {

    case 'deposit':
      showDepositButton();
      break;

    case 'withdraw':
      loadWithdrawForm(link.href);
      showWithdrawButton();
      break;
  }

});

Nó tiết kiệm cho bạn trong mã khách hàng của bạn như:

if (balance <= 0 && negativeBalanceAllowed === false) {
  showWithdrawButton();
}

Bạn có thể thực hiện một vị trí tiêu cực được phép (ví dụ bằng cách vay tiền) mà không thay đổi khách hàng của bạn.