ไฮเปอร์มีเดีย (HATEOAS) มีประโยชน์อย่างไร?


17

ฉันไม่เข้าใจถึงประโยชน์ของ HATEOAS สำหรับ API ที่ใช้สำหรับโปรแกรม (ตรงข้ามกับมนุษย์ที่เรียกดู API ของคุณโดยตรง) แน่นอนว่าลูกค้าไม่ได้ถูกผูกไว้กับสคีมา URL แต่พวกเขาจะถูกผูกไว้กับสคีมาข้อมูลซึ่งเป็นสิ่งเดียวกันในใจของฉัน

ตัวอย่างเช่นสมมติว่าฉันต้องการดูรายการในคำสั่งซื้อสมมติว่าฉันได้ค้นพบหรือทราบ URL การสั่งซื้อแล้ว

HATEOAS:

order = get(orderURL);
item = get(order.itemURL[5]);

ไม่ใช่ HATEOAS:

order = get(orderURL);
item = get(getItemURL(order,5));

ในรุ่นแรกฉันต้องรู้ข้อเท็จจริงว่าวัตถุใบสั่งมีเขตข้อมูล itemURL ในรุ่นที่สองฉันต้องรู้วิธีสร้าง URL รายการ ในทั้งสองกรณีฉันต้อง "รู้" ก่อนล่วงหน้าดังนั้น HATEOAS ทำอะไรให้ฉันได้บ้าง


1
get(orderURL);the fact that the order object has an itemURL fieldควรจะบอกคุณ
yannis

เมื่อคุณเขียนแอปพลิเคชันไคลเอนต์คุณต้องรู้ล่วงหน้าว่าฟิลด์คืออะไร
Pace

ไม่นั่นคือประเด็นหลักของ HATEOAS คุณไม่จำเป็นต้องรู้ล่วงหน้าว่าฟิลด์นี้คืออะไรคุณต้องมีคะแนนมาตรฐานเพียงไม่กี่ชุดเท่านั้นและส่วนที่เหลือสามารถค้นพบได้ "หลักการคือไคลเอนต์โต้ตอบกับแอปพลิเคชั่นเครือข่ายทั้งหมดผ่านไฮเปอร์มีเดียที่แอพพลิเคชั่นเซิร์ฟเวอร์จัดทำขึ้นแบบไดนามิกไคลเอนต์ REST ไม่จำเป็นต้องมีความรู้มาก่อนเกี่ยวกับวิธีการโต้ตอบกับแอพพลิเคชั่นหรือเซิร์ฟเวอร์ใด ๆ
yannis

8
แอปพลิเคชันควรจะรับไอเท็มจากคำสั่งซื้ออย่างไรหากแอปพลิเคชันไม่ทราบว่าคำสั่งซื้อนั้นมีรายการอยู่ใช่หรือไม่ การค้นพบใช้งานได้สำหรับการเรียกดูด้วยตนเอง
Pace

คนที่ตัวเองกำลังพูดถึงอยู่ที่นี่: roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven
Thiago Silva

คำตอบ:


6

ความแตกต่างอย่างหนึ่งคือสคีมานั้นหวังว่าจะเป็นมาตรฐานหรืออย่างน้อยก็สามารถนำมาใช้ซ้ำได้โดยผู้อื่น

ตัวอย่างเช่นสมมติว่าคุณใช้ Twitter API และคุณต้องการสนับสนุน StatusNet ด้วย (หรือแทน) เนื่องจากพวกเขาใช้ตัวแบบข้อมูลเดียวกันกับ Twitter หาก API เป็นไปตาม HATEOAS ตอนนี้คุณเพียงแค่เปลี่ยน URL หลัก หากไม่เป็นเช่นนั้นตอนนี้คุณต้องเปลี่ยนURL แต่ละอันจากรหัส

แน่นอนถ้าคุณต้องการเปลี่ยนรหัสเพื่อใส่ URL จุดเริ่มต้นของบริการอย่างไรก็ตามอาจไม่เป็นประโยชน์ มันส่องจริง ๆ คือถ้า URL นั้นถูกแทรกแบบไดนามิก ตัวอย่างเช่นหากคุณกำลังสร้างบริการเช่น Twillio ซึ่งจะโต้ตอบกับ API ของผู้ใช้


นั่นเป็นจุดที่น่าสนใจที่ฉันไม่ได้พิจารณา
Pace

@ YanisRizos: อืมฉันไม่เห็นว่าฉันพูดว่า HATEOAS เป็นมาตรฐาน ฉันบอกว่าschema (ข้อมูล) หวังว่าเป็นมาตรฐาน " ในคำศัพท์ REST นั้นจะเป็นประเภทสื่อ
AndréParamés

ในการอ่านครั้งที่สองคุณพูดถูก
yannis

2
ใช่ถ้าคุณสมมติว่าชื่อ rel สำหรับลิงค์นั้นเหมือนกัน แต่การพูดโดยทั่วไปและไม่เพียง แต่ในตัวอย่างเฉพาะที่คุณพูดถึงโปรแกรมเมอร์ทุกคนในโลกไม่จำเป็นต้องเลือกชื่อเดียวกันสำหรับการกระทำที่คล้ายกันหรือเทียบเท่า ประโยชน์นี้มาจากโปรแกรมเมอร์ที่ยอมรับการตั้งชื่อและพารามิเตอร์ทั่วไป
derloopkat

8
  1. Explorable API: มันอาจฟังดูไม่สำคัญ แต่อย่าประมาทพลังของ API ที่สามารถมองเห็นได้ ความสามารถในการเรียกดูข้อมูลทำให้ผู้พัฒนาไคลเอ็นต์สามารถสร้างแบบจำลองทางจิตใจของ API และโครงสร้างข้อมูลได้ง่ายขึ้นมาก

  2. เอกสารประกอบแบบอินไลน์: การใช้ URL เป็นความสัมพันธ์ของลิงก์สามารถชี้นักพัฒนาไคลเอ็นต์ไปยังเอกสารประกอบ

  3. ตรรกะของไคลเอ็นต์อย่างง่าย: ไคลเอนต์ที่ติดตาม URL แทนที่จะสร้างเองควรง่ายกว่าในการนำไปใช้และบำรุงรักษา

  4. เซิร์ฟเวอร์รับสิทธิ์ความเป็นเจ้าของโครงสร้าง URL: การใช้ไฮเปอร์มีเดียลบความรู้ที่ฮาร์ดโค้ดของลูกค้าเกี่ยวกับโครงสร้าง URL ที่ใช้โดยเซิร์ฟเวอร์

  5. การปิดการโหลดเนื้อหาไปยังบริการอื่น ๆ : Hypermedia เป็นสิ่งจำเป็นเมื่อทำการโหลดเนื้อหาไปยังเซิร์ฟเวอร์อื่น (เช่น CDN)

  6. การกำหนดเวอร์ชันด้วยลิงก์: Hypermedia ช่วยกำหนดเวอร์ชันของ API

  7. การใช้งานที่หลากหลายของบริการเดียวกัน: Hypermedia เป็นสิ่งจำเป็นเมื่อมีการใช้งานที่เหมือนกันหลายอย่างของการบริการที่มีอยู่ (และไคลเอนต์หนึ่งต้องเข้าถึงมากกว่าหนึ่งของพวกเขา)

คุณสามารถหาคำอธิบายเชิงลึกของสัญลักษณ์แสดงหัวข้อย่อยเหล่านี้ได้ที่นี่: http://soabits.blogspot.no/2013/12/selling-benefits-of-hypermedia.html


> Off การโหลดเนื้อหาไปยังบริการอื่น ๆ : Hypermedia เป็นสิ่งจำเป็นเมื่อ off-loading เนื้อหาไปยังเซิร์ฟเวอร์อื่น ๆ (เช่น CDN) ไม่มันไม่ใช่. คุณสามารถเก็บลิงค์เดิมไว้และใช้ CDN
Bruno Costa
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.