5 Câu hỏi: REST HATEOAS hữu ích / quan trọng như thế nào (mức trưởng thành 3)?

câu hỏi được tạo ra tại Mon, Dec 2, 2013 12:00 AM

Tôi đang tham gia vào một dự án nơi một số thành viên nhóm cao cấp tin rằng API REST phải tuân thủ 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 tại sao nhiều người không thực hiện nó. Tôi có thể nghĩ ra các lý do như thêm phức tạp, thiếu khung (phía máy chủ và máy khách), mối quan tâm về hiệu suất và ...

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

    
89
5 Câu trả lời                              5                         

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 gây thêm khó khăn cho kiến ​​trúc REST.

Mọi người không làm HATEOAS vì tất cả các lý do bạn đề xuất: thật khó khăn. Nó tăng thêm độ 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ó).

TUY NHIÊN, hàng tỷ người trải nghiệm những lợi ích của REST ngày hôm nay. Bạn có biết URL "thanh toán" tại Amazon không? Tôi không. Tuy nhiên, tôi có thể kiểm tra mỗi ngày. URL đó đã thay đổi? 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 đã loại bỏ ứng dụng khách tự động của Amazon. Một số người có khả năng đánh hơi lưu lượng truy cập web, đọc các trang HTML, v.v. để tìm liên kết nào sẽ 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 đó đã thất bại - vì các liên kết bị hỏng.

Tuy nhiên, những người lướt web thông thường có thể mua sắm cả ngày mà không gặp trở ngại nào.

Đó là REST hoạt động, nó chỉ được tăng cường bởi con người có khả năng diễn giải và giao tiếp với giao diện dựa trên văn bản, nhận ra một đồ họa nhỏ với giỏ hàng và nói ra ý nghĩa thực sự của nó.

Hầu hết mọi người viết phần mềm không làm điều đó. Hầu hết mọi người viết khách hàng tự động không quan tâm. Hầu hết mọi người thấy dễ dàng sửa chữa khách hàng của họ khi họ phá vỡ hơn là kỹ sư ứng dụng không bị hỏng ngay từ đầu. Hầu hết mọi người chỉ đơn giản là không có đủ khách hàng khi có vấn đề.

Nếu bạn đang viết API nội bộ để liên lạc giữa hai hệ thống với bộ phận hỗ trợ kỹ thuật và CNTT chuyên gia ở cả hai phía lưu lượng, nhữ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 sẽ mua cho bạn không có gì. 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 để quan trọng.

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ể yêu cầu mọi người thay đổi mã khách hàng một cách bất chợt khi tương tác với hệ thống của họ. Lịch trình phát triển máy chủ không giống như lịch trình phát triển máy khách. Những thay đổi đột ngột đối với API đơn giản là không thể chấp nhận được đối với mọi người có liên quan, vì nó làm gián đoạn lưu lượng truy cập và hoạt động của cả hai bên.

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

Một máy khách ủy thác phần lớn luồng công việc của nó cho máy chủ và hành động theo kết quả sẽ mạnh mẽ hơn đối với các thay đổi của máy chủ so với máy khách không hoạt động.

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 được sử dụng nội bộ. Nếu nó bị hỏng, họ sẽ sửa nó và họ đã nhận ra rằng trong các hoạt động bình thường của họ.

Tính linh hoạt, cho dù từ REST hay bất cứ thứ gì khác, tạo ra sự 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" và được thực hiện. Khi bạn thêm các khái niệm trừu tượng và hội thảo vào các hệ thống, thì mọi thứ trở nên khó khăn hơn, nhiều nồi hơi hơn, nhiều mã hơn để kiểm tra.

Phần lớn REST thất bại trong gạch đầu dòng "bạn sẽ 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ư được trình bày. REST không đẩy các công cụ qua lại trên HTTP. Chưa bao giờ, nó cao hơn thế nhiề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. Đây 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.

    
178
2013-12-02 19: 31: 27Z
  1. 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 tưởng tượng: câu hỏi REST thực sự quan trọng đến mức nào. Chết tiệt, tôi đã làm một số việc vì lý do đó để sử dụng đạn trong một cuộc họp sắp tới khi tôi tìm thấy chủ đề này.
    2014-04-16 22: 57: 18Z
  2. nghìn lượt thích ++
    2015-03-08 20: 31: 38Z
  3. cảm ơn chúa (hoặc mã), ai đó cũng đang nói về những bất lợi của HATEOAS!
    2016-12-26 18: 48: 35Z
  4. Có bất kỳ lợi thế nào khác sau đó là khả năng dễ dàng thay đổi URL không? Bạn không thể 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ể hoạt động với thứ gì đó mới. Ngoài ra, bạn chỉ chuyển từ xây dựng các URL biết sang biết tên hành động.
    2018-01-15 12: 34: 48Z
  5. Nếu người tiêu dùng API không biết gì thì chỉ có thể ủy thác hành động của người dùng 1: 1
    2018-01-15 12: 37: 49Z

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 yêu: Nghe có vẻ tầm thường nhưng đừng đánh giá thấp sức mạnh của một API đáng kinh ngạc. Khả năng duyệt xung quanh dữ liệu giúp các nhà phát triển ứng dụng khách dễ dàng hơn nhiều trong việc 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 URL làm quan hệ liên kết có thể hướng nhà phát triển ứng dụng khách đến tài liệu.

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

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

  5. Tắt tải nội dung sang các dịch vụ khác: Hypermedia là cần thiết khi tắt tải nội dung sang 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ụ /API: Hypermedia là cần thiết khi tồn tại nhiều triển khai của cùng một dịch vụ /API. Ví dụ, một dịch vụ có thể là API blog có tài nguyên để thêm bài đăng và nhận xét. Nếu dịch vụ được chỉ định theo quan hệ liên kết thay vì URL được mã hóa cứng thì cùng một dịch vụ có thể được khởi tạo nhiều lần tại các URL khác nhau, được lưu trữ bởi các công ty khác nhau nhưng vẫn có thể truy cập thông qua cùng một nhóm liên kết được xác định bởi một khách hàng.

Bạn có thể tìm thấy lời giải thích sâu sắc về các gạch đầ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: 19

2018-09-18 04: 49: 17Z
  1. Nhiều triển khai của cùng một dịch vụ: bạn có thể giải thích không? Tôi không thấy nó giúp như thế nào.
    2018-09-17 19: 11: 06Z
  2. Tôi đã cố gắng giải thích nó trong văn bản. Nó có giúp gì không?
    2018-09-18 04: 49: 53Z
Mức độ trưởng thành 3 của

của Richardson là có giá trị và nên được thông qua. Jørn Wildt đã tóm tắt một số lợi thế vàmột câu trả lời khác, bởi Wilt, bổ sung cho nó rất tốt.

Tuy nhiên, mức trưởng thành cấp 3 của Richardson không giống với HATEOAS của Fielding. Mức độ trưởng thành 3 của Richardson chỉ là về thiết kế API. HATEOAS của Fielding cũng nói về thiết kế API, nhưng cũng quy định rằng phần mềm máy khách không nên cho rằng tài nguyên có cấu trúc cụ thể ngoài cấu trúc được xác định bởi loại phương tiện. Điều này đòi hỏi một khách hàng rất chung chung, như trình duyệt web, không có kiến ​​thức về các trang web cụ thể. Vì Roy Fielding đã đặt ra thuật ngữ REST và đã đặt HATEOAS làm yêu cầu tuân thủ REST, nên câu hỏi là: chúng ta có muốn áp dụng HATEOAS không và nếu không, chúng ta vẫn có thể gọi API RESTful của mình hay không? Tôi nghĩ rằng chúng ta có thể. Hãy để tôi giải thích.

Giả sử chúng ta đã đạt được HATEOAS. Phía máy khách của ứng dụng bây giờ rất chung chung, nhưng rất có thể, trải nghiệm người dùng rất tệ, vì không có bất kỳ kiến ​​thức nào về ngữ nghĩa của 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 không sao, API của chúng tôi thực sự RESTful.

Bây giờ, giả sử chúng tôi xây dựng ứng dụng khách thứ hai trên đầu 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 được mã hóa cứng về các tài nguyên. Nó hiển thị một chiếc xe hơi và một ngôi nhà theo những cách khác nhau.

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

Tôi khuyên nên xây dựng API RESTful, tức là API mà khách hàng chung có thể triển khai về lý thuyết , nhưng trong hầu hết các trường hợp, bạn cần một số thông tin được mã hóa cứng về tài nguyên trong khách hàng của bạn để đáp ứng các yêu cầu về khả năng sử dụng. Tuy nhiên, hãy cố gắng mã hóa càng ít càng tốt, để giảm 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ủa mình có tên là JAREST .

    
9
2018-12-13 12: 13: 34Z

Chúng tôi đang xây dựng API cấp 3 REST trong đó phản hồi của chúng tôi là trong HAL-Json. HATEOAS là tuyệt vời cho cả phía trước và phía sau nhưng nó đi kèm với những thách thức. Chúng tôi đã thực hiện một số tùy chỉnh /bổ sung để quản lý ACL bên trong phản hồi HAL-Json (không phá vỡ tiêu chuẩn HAL-Json).

Những lợi thế lớn nhất đối với HATEOAS tôi thấy là chúng ta không cần phải viết /đoán bất kỳ url nào trên ứng dụng front-end của mình. Tất cả những gì bạn cần là một điểm vào (49 310) và từ đó, bạn có thể duyệt qua các tài nguyên bằng các liên kết hoặc liên kết được cung cấp bên trong phản hồi. Giống như phiên bản đó có thể được xử lý dễ dàng, đổi tên /thay thế các url, mở rộng tài nguyên với các quan hệ bổ sung mà không vi phạm mã mặt trước.

Bộ nhớ đệm tài nguyên ở mặt trước là một miếng bánh sử dụng các liên kết tự. Chúng tôi cũng đẩy tài nguyên cho khách hàng thông qua kết nối ổ cắm, vì chúng cũng được hiển thị trong HAL, chúng tôi có thể dễ dàng thêm chúng vào bộ đệm theo cùng một cách.

Một ưu điểm khác của việc sử dụng HAL-Json là rõ ràng mô hình phản hồi sẽ trông như thế nào, vì có một tiêu chuẩn được lập thành tài liệu nên được tuân theo.

Một trong những tùy chỉnh của chúng tôi là chúng tôi đã thêm một đối tượng hành động bên trong đối tượng tự liên kết lộ ra mặt trước mà hành động hoặc hoạt động CRUD mà người dùng được xác thực được phép thực hiện trên tài nguyên tương ứng (49 310, 49 310, 49 310, 49 310 , 49 310). Như thế này ACL mặt trước của chúng tôi hoàn toàn bị quyết định bởi phản hồi API REST của chúng tôi, chuyển hoàn toàn trách nhiệm này sang mô hình back-end.

Vì vậy, để đưa ra một ví dụ nhanh, bạn có thể có một đối tượng bài đăng trong HAL-Json trông giống như thế này:

 49 310

Bây giờ, tất cả những gì chúng ta phải làm ở mặt trước là xây dựng một 49 310 với phương thức 49 310 để kiểm tra xem hành động chúng ta muốn thực hiện có nằm trong đối tượng hành động hay không.

Hiện tại trên giao diện người dùng có vẻ đơn giản như: 49 310

Tôi nghĩ REST cấp 3 là tuyệt vời, nhưng nó có thể dẫn đến một số vấn đề đau đầu. Bạn sẽ cần có một sự hiểu biết lớn về REST và nếu bạn muốn làm việc với REST cấp 3, tôi khuyên bạn nên tuân thủ nghiêm ngặt khái niệm REST nếu không bạn sẽ dễ bị lạc đường khi thực hiện nó.

Trong trường hợp của chúng tôi, chúng tôi có lợi thế là chúng tôi đang xây dựng cả mặt trước và mặt sau nhưng về nguyên tắc, nó KHÔNG nên tạo ra sự khác biệt. Nhưng một cạm bẫy phổ biến tôi đã thấy trong đội của chúng tôi làrằng một số nhà phát triển cố gắng giải quyết các vấn đề về mặt trước (kiến trúc) bằng cách thay đổi mô hình back-end của họ để nó "phù hợp" với nhu cầu của front-end.

    
4
2018-12-13 14: 45: 30Z
  1. Câu trả lời rất hay. Tôi nghĩ một ví dụ thực tế như vậy là những gì người hỏi ban đầu đang tìm kiếm.
    2018-12-13 12: 17: 54Z

Tôi đã sử dụng HATEOAS trong một số dự án thực tế, nhưng với cách hiểu 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 chỉ 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 loại tài liệu HTML, siêu liên kết đến các tài nguyên liên quan và biểu mẫu HTML để hiển thị chức năng cho các động từ khác ngoài GET. . Một ứ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 tuân theo điều này. (HATEOAS dành riêng cho HTML.)

    
2
2013-12-02 20: 38: 12Z
https://hostname
nguồn đặt đây