Câu hỏi Làm thế nào hữu ích / quan trọng là REST HATEOAS (độ trưởng thành cấp 3)?


Tôi đang tham gia vào một dự án mà một số thành viên nhóm cao cấp tin rằng REST API phải tuân theo HATEOAS và thực hiện tất cả các mức độ trưởng thành của Richardson (http://martinfowler.com/articles/richardsonMaturityModel.html)!

AFAIK hầu hết các triển khai REST không tuân thủ HATEOAS và cần có một lý do chính đáng khiến nhiều người không thực hiện nó. Tôi có thể nghĩ ra các lý do như độ phức tạp được thêm vào, thiếu các khung công tác (các máy chủ và phía máy khách), mối quan tâm về hiệu suất và ...

Bạn nghĩ sao? Bạn đã có kinh nghiệm với HATEOAS trong một dự án thế giới thực chưa?


76
2017-12-02 19:11


gốc




Các câu trả lời:


Không ai trong cộng đồng REST nói REST dễ dàng. HATEOAS chỉ là một trong những khía cạnh làm tăng thêm khó khăn cho kiến ​​trúc REST.

Mọi người không làm HATEOAS vì tất cả những lý do bạn đề xuất: thật khó. Nó cho biết thêm sự phức tạp cho cả phía máy chủ và máy khách (nếu bạn thực sự muốn hưởng lợi từ nó).

BAO GIỜ, hàng tỷ người trải nghiệm những lợi ích của REST ngày nay. Bạn có biết URL "thanh toán" ở Amazon không? Tôi không. Tuy nhiên, tôi có thể kiểm tra mỗi ngày. URL đó đã thay đổi chưa? Tôi không biết, tôi không quan tâm.

Bạn có biết không quan tâm? Bất cứ ai đã viết một màn hình đã quét máy khách tự động của Amazon. Ai đó có khả năng đã đánh cắp lưu lượng truy cập web một cách cẩn thận, đọc các trang HTML, v.v. để tìm những liên kết nào cần gọi khi nào và với tải trọng nào.

Và ngay sau khi Amazon thay đổi quy trình nội bộ và cấu trúc URL của họ, những khách hàng được mã hóa cứng này không thành công - bởi vì các liên kết đã bị hỏng.

Tuy nhiên, những người lướt web bình thường đã có thể mua sắm cả ngày với khó khăn lắm.

Đó là REST trong hành động, nó chỉ được tăng cường bởi con người có thể giải thích và intuit văn bản dựa trên giao diện, nhận ra một đồ họa nhỏ với một giỏ mua hàng, và suss ra những gì mà thực sự có nghĩa là.

Hầu hết mọi người viết phần mềm không làm điều đó. Hầu hết các folks viết tự động khách hàng không quan tâm. Hầu hết mọi người tìm thấy nó dễ dàng hơn để sửa chữa khách hàng của họ khi họ phá vỡ hơn kỹ sư ứng dụng để không phá vỡ ở nơi đầu tiên. Hầu hết mọi người chỉ đơn giản là không có đủ khách hàng ở những nơi quan trọng.

Nếu bạn đang viết một API nội bộ để giao tiếp giữa hai hệ thống với sự hỗ trợ kỹ thuật chuyên môn và CNTT trên cả hai mặt của lưu lượng, người có thể giao tiếp thay đổi nhanh chóng, đáng tin cậy và với lịch thay đổi, thì REST không mua cho bạn thứ gì cả. Bạn không cần nó, ứng dụng của bạn không đủ lớn, và nó không sống đủ lâu để có vấn đề.

Các trang web lớn với cơ sở người dùng lớn có vấn đề này. Họ không thể chỉ yêu cầu folks thay đổi mã khách hàng của họ trên một whim khi tương tác với hệ thống của họ. Lịch trình phát triển của máy chủ không giống như lịch trình phát triển của khách hàng. Các thay đổi đột ngột đối với API đơn giản là không thể chấp nhận được đối với tất cả mọi người có liên quan, vì nó phá vỡ lưu lượng truy cập và hoạt động ở cả hai bên.

Vì vậy, một hoạt động như vậy sẽ rất có thể được hưởng lợi từ HATEOAS, vì nó dễ dàng hơn cho phiên bản, dễ dàng hơn cho các khách hàng lớn tuổi để di chuyển, dễ dàng hơn để được tương thích ngược hơn không.

Một máy khách đại diện cho nhiều luồng công việc của nó tới máy chủ và hành động dựa trên các kết quả sẽ mạnh mẽ hơn nhiều đối với các thay đổi máy chủ hơn là một máy khách không thực hiện.

Nhưng hầu hết mọi người không cần sự linh hoạt đó. Họ đang viết mã máy chủ cho 2 hoặc 3 phòng ban, tất cả đều là sử dụng nội bộ. Nếu nó phá vỡ, họ sửa chữa nó, và họ đã thừa nhận rằng trong hoạt động bình thường của họ.

Tính linh hoạt, dù từ REST hay bất kỳ thứ gì khác, đều phức tạp. Nếu bạn muốn nó đơn giản, và nhanh chóng, thì bạn không làm cho nó linh hoạt, bạn "chỉ cần làm điều đó", và được thực hiện. Khi bạn thêm trừu tượng và dereferencing vào hệ thống, sau đó công cụ được khó khăn hơn, nhiều hơn nữa nồi hơi, nhiều mã để kiểm tra.

Phần lớn REST thất bại trong "điểm bạn không cần nó". Cho đến khi, tất nhiên, bạn làm.

Nếu bạn cần nó, sau đó sử dụng nó, và sử dụng nó như nó được đặt ra. REST không chuyển đổi qua lại HTTP. Chưa bao giờ, nó cao hơn nhiều so với điều đó.

Nhưng khi bạn cần REST, và bạn sử dụng REST, thì HATEOAS là một điều cần thiết. Đó là một phần của gói và là chìa khóa cho những gì làm cho nó hoạt động.


148
2017-12-02 19:31



Tôi cảm thấy như bạn nên có ít nhất một nghìn lượt thích cho câu trả lời này. Thành thật mà nói, tôi phải hình dung: Câu hỏi REST thực sự quan trọng đến mức nào một chút. Địa ngục, tôi đã làm một số googling chỉ vì lý do đó cho đạn dược sử dụng trong một cuộc họp sắp tới khi tôi tìm thấy chủ đề này. - nograde
nghìn lượt thích ++ - felipecao
cảm ơn chúa (hay mã), ai đó cũng đang nói về những bất lợi của HATEOAS! - IlliakaillI
Có lợi thế nào khác sau đó khả năng dễ dàng thay đổi URL? Bạn không thể chỉ thêm các tùy chọn mới vì không giống như con người, chương trình không thể làm việc với một cái gì đó mới. Ngoài ra, bạn chỉ chuyển từ xây dựng các URL biết đến biết tên hành động. - Jimmy T.
Nếu người tiêu dùng API không biết bất cứ điều gì, nó chỉ có thể ủy quyền hành động của người dùng 1: 1 - Jimmy T.


Có, tôi đã có một số kinh nghiệm với hypermedia trong API. Dưới đây là một số lợi ích:

  1. API đáng chú ý: Nó nghe có vẻ tầm thường nhưng không đánh giá thấp sức mạnh của một API đáng kinh ngạc. Khả năng duyệt qua dữ liệu giúp các nhà phát triển ứng dụng khách dễ dàng xây dựng mô hình tinh thần của API và cấu trúc dữ liệu của nó.

  2. Tài liệu nội tuyến: Việc sử dụng các URL như các mối quan hệ liên kết có thể hướng các nhà phát triển ứng dụng đến tài liệu.

  3. Logic máy khách đơn giản: Một khách hàng chỉ đơn giản là theo các URL thay vì xây dựng chính chúng, cần phải thực hiện và duy trì dễ dàng hơn.

  4. Máy chủ sở hữu cấu trúc URL: Việc sử dụng hypermedia loại bỏ kiến ​​thức mã hóa cứng của khách hàng về cấu trúc URL được máy chủ sử dụng.

  5. Tắt tải nội dung cho các dịch vụ khác: Hypermedia là cần thiết khi tắt tải nội dung cho các máy chủ khác (ví dụ: CDN).

  6. Phiên bản có liên kết: Hypermedia giúp phiên bản API.

  7. Nhiều triển khai của cùng một dịch vụ: Hypermedia là một điều cần thiết khi nhiều triển khai cùng một dịch vụ tồn tại (và một khách hàng cần truy cập nhiều hơn một trong số chúng).

Bạn có thể tìm thấy giải thích chi tiết về các dấu đầu dòng này tại đây: http://soabits.blogspot.no/2013/12/selling-benefits-of-hypermedia.html

(có một câu hỏi tương tự ở đây: https://softwareengineering.stackexchange.com/questions/149124/what-is-the-benefit-of-hypermedia-hateoas nơi tôi đã đưa ra lời giải thích tương tự)


14
2017-12-11 09:04





Tôi nghĩ rằng một API có thể được gọi là RESTful, ngay cả khi phía máy khách của ứng dụng không tuân theo các nguyên tắc HATEOAS. Trong hầu hết các trường hợp, khách hàng phải vi phạm HATEOAS để đáp ứng các yêu cầu về khả năng sử dụng. Hãy để tôi giải thích.

HATEOAS không chỉ đặt một ràng buộc ở phía máy chủ của ứng dụng mà còn ở phía máy khách. Khách hàng không nên giả định rằng một tài nguyên có cấu trúc cụ thể ngoài cấu trúc được định nghĩa bởi loại phương tiện. Máy chủ sẽ cung cấp API hỗ trợ ứng dụng khách như vậy.

Bây giờ, giả sử chúng ta đã đạt được điều này. Phía máy khách của ứng dụng hiện nay rất chung chung, nhưng rất có thể, trải nghiệm người dùng là xấu, bởi vì không có kiến ​​thức về ngữ nghĩa của các tài nguyên, việc trình bày các tài nguyên không thể được điều chỉnh để phản ánh các ngữ nghĩa đó. Nếu tài nguyên 'xe hơi' và tài nguyên 'nhà' có cùng loại phương tiện (ví dụ: ứng dụng / json), thì chúng sẽ được trình bày cho người dùng theo cùng một cách, ví dụ như một bảng thuộc tính (cặp tên / giá trị).

Nhưng được rồi, API của chúng tôi thực sự là RESTful.

Bây giờ, giả sử chúng ta xây dựng một ứng dụng khách thứ hai trên đầu trang của API này. Khách hàng thứ hai này vi phạm các ý tưởng của HATEOAS và có thông tin mã hóa cứng về tài nguyên. Nó hiển thị một chiếc xe và một ngôi nhà theo những cách khác nhau.

API có thể vẫn được gọi là RESTful không? Tôi nghĩ vậy. Nó không phải là lỗi của API mà một trong những khách hàng của nó đã vi phạm HATEOAS.

Tôi khuyên bạn nên xây dựng các API RESTful, tức là các API mà một máy khách chung có thể được triển khai theo lý thuyếtnhưng trong hầu hết các trường hợp, bạn cần một số thông tin mã hóa cứng về tài nguyên trong ứng dụng khách của bạn để đáp ứng các yêu cầu. Tuy nhiên, hãy cố gắng mã hóa ít nhất có thể, để giảm bớt sự phụ thuộc giữa máy khách và máy chủ.

Tôi đã bao gồm một phần trên HATEOAS trong mẫu triển khai REST được gọi là JAREST.


5
2017-10-24 16:14





Tôi đã sử dụng HATEOAS trong một số dự án thực sự, nhưng với một cách giải thích khác với Richardson. Nếu đó là những gì ông chủ của bạn muốn, thì tôi đoán bạn nên làm điều đó. Tôi lấy HATEOAS để có nghĩa là tài nguyên của bạn nên bao gồm một tài liệu HTML, siêu liên kết đến các tài nguyên có liên quan và các biểu mẫu HTML để hiển thị chức năng cho các động từ khác ngoài GET. (Đây là khi loại Chấp nhận là văn bản / html - các loại nội dung khác không yêu cầu các tính năng bổ sung này.) Tôi không biết niềm tin rằng tất cả các tài nguyên REST trong toàn bộ ứng dụng của bạn phải được dán cùng nhau đến từ đâu. Ứng dụng mạng phải chứa nhiều tài nguyên có thể có hoặc không liên quan trực tiếp. Hoặc tại sao người ta tin rằng XML, JSON và các loại khác cần phải làm theo điều này. (HATEOAS là HTML cụ thể.)


2
2017-12-02 20:38