REST และ HATEOAS เป็นสถาปัตยกรรมที่ดีสำหรับบริการเว็บหรือไม่?

หากฉันเข้าใจอย่างถูกต้อง REST ได้รับการยอมรับอย่างเป็นทางการจาก Roy Fielding เป็นแบบจำลองเชิงพรรณนาของสถาปัตยกรรมของเว็บ AFAIK Fielding ไม่ได้เรียกร้อง REST ว่าดีอะไรเขาแค่อธิบายสถาปัตยกรรมแบบพฤตินัยของเว็บ เว็บได้มาถึงจุดนี้พิสูจน์แล้วว่าระบบไฮเปอร์เท็กซ์แบบกระจายที่ประสบความสำเร็จอย่างมากดังนั้นการตรวจสอบ REST ในรูปแบบนี้จึงเป็นสถาปัตยกรรมที่ประสบความสำเร็จสำหรับโดเมนของไฮเปอร์มีเดียแบบกระจาย

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

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

AFAIK Fielding ไม่ได้เรียกร้อง REST ว่าดีอะไรเขาแค่อธิบายสถาปัตยกรรมแบบพฤตินัยของเว็บ

ฉันคิดว่ามันคงน้อยไปหน่อย ที่เหลือก็เป็นหลังจากที่ทุกการแจกแจงของรูปแบบสถาปัตยกรรมที่ฟีลดิงถูกใช้เป็นหัวหน้าสถาปนิกของHTTP / 1.1 สเปค

แต่จริงๆแล้วมีเหตุผลใดที่จะคิดว่า REST เป็นสถาปัตยกรรมที่ต้องการสำหรับโดเมนนี้หรือไม่? มีหลักฐานว่า HATEOAS เป็นหลักการออกแบบที่มีประโยชน์สำหรับการสื่อสารระหว่างเครื่องจักรกับเครื่องหรือไม่?

"มันขึ้นอยู่กับ". HATEOAS เป็นส่วนหนึ่งของอินเตอร์เฟซเครื่องแบบข้อ จำกัด ของส่วนที่เหลือ

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

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

มันใช้งานได้

แน่นอนว่ามันไม่ใช่สากล ฟีลดิงในปี 2551เขียนว่า:

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

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

ในกรณีที่เครื่องต่อเครื่องจักรยากขึ้นคือคุณสูญเสียความสามารถของมนุษย์ในการจับคู่ความหมายของการเป็นตัวแทน ลูกค้าสามารถรับรู้ได้ด้วยเพียงแค่ประเภทสื่อ แต่โดยปกติแล้วเราจะมีคนคอยดูความหมายที่แฝงเร้นเพื่อหาความหมาย

schema.orgเป็นส่วนหนึ่งของความพยายามในการสร้างคำศัพท์ที่เครื่องอ่านได้ ตัวแทนเครื่องใช้ไคลเอนต์เพื่อค้นหาคำแนะนำความหมายและใช้ความเข้าใจของตัวเองของความหมายในการเลือกการกระทำที่ถูกต้องที่จะใช้

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

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

ไม่ 'การพักเต็มที่' นั้นยอดเยี่ยมมาก

ดังที่เห็นได้จากการขาดคนที่ใช้ HATEOS ใน API ของพวกเขาและข้อโต้แย้งที่ไม่สิ้นสุดซึ่งกริยา HTTP ที่จะใช้สำหรับการโทรเฉพาะ

แต่คุณต้องยอมรับว่าทำไม REST จึงได้รับความนิยม ก่อนที่จะมีการยอมรับมีหลายโปรโตคอลที่ซับซ้อนอย่างบ้าคลั่งเช่น ebXML และ SOAP ที่เกี่ยวข้องกับการตอบรับ, หมดเวลา, รหัสการสนทนาและรัฐ

ทำให้สิ่งเหล่านี้ทำงานได้และจากนั้นการอธิบายให้กับผู้บริโภคของ api นั้นเป็นงานที่ยาก "ทำไมฉันไม่ทำ GET ด้วย id ที่ฉันต้องการในสตริงการสืบค้นแล้วส่งข้อมูลให้ฉัน" เป็นคำถามที่ชัดเจนและพบบ่อย

แล้วปัญหาที่สองคือ XML, JavaScript ไม่ได้เข้าใจมัน schemas มีอาการปวดในตูดและคุณจะจบลงด้วยไฟล์ txt <MyLongObjectName>ขนาดใหญ่ส่วนใหญ่ประกอบด้วย ดังนั้นผู้คนเริ่มใช้ JSON แทน

ตอนนี้ REST มีลัทธิอยู่รอบตัว แต่เนื่องจากกฎนั้นคลุมเครือจึงไม่ป้องกันคุณที่จะใช้ API ที่ใช้งานได้ซึ่งง่ายพอที่ผู้บริโภคจะ 'เพิ่งได้รับ' และใช้งานได้โดยไม่ต้องขึ้นเครื่อง 6 เดือน กระบวนการ.

โปรดทราบว่า Roy ไม่ใช่ผู้ประดิษฐ์ดั้งเดิมของหลักการส่วนใหญ่ของ REST เขารวบรวมหลักการหลายอย่างที่เป็นที่รู้จักกันในการทำงานในระบบก่อนหน้านี้เพื่อแก้ไขปัญหาเฉพาะต่างๆ ส่วนที่เหลือเป็นเพียงข้อสรุปตามธรรมชาติของการใช้หลักการเหล่านี้ในสถาปัตยกรรมเดียว

ก่อนที่ Roy Fielding จะเขียนวิทยานิพนธ์ของเขาใน REST HTTP นั้นได้รับการออกแบบมาตามหลักการที่ต่อมากลายเป็นที่รู้จักในชื่อว่า REST ในบทสรุปของวิทยานิพนธ์ของเขาเขาเขียนว่า:

เมื่อเริ่มต้นความพยายามของเราภายใน Internet Engineering Taskforce เพื่อกำหนด Hypertext Transfer Protocol (HTTP / 1.0) [19] ที่มีอยู่แล้วและออกแบบส่วนขยายสำหรับมาตรฐานใหม่ของ HTTP / 1.1 [42] และ Uniform Resource Identifiers (URI) [21] ] ฉันตระหนักถึงความต้องการรูปแบบการทำงานของเวิลด์ไวด์เว็บ รูปแบบในอุดมคติของการโต้ตอบภายในแอปพลิเคชันเว็บโดยรวมเรียกว่ารูปแบบสถาปัตยกรรม Representational State Transfer (REST) ​​กลายเป็นรากฐานของสถาปัตยกรรมเว็บสมัยใหม่ที่ให้หลักการที่เป็นแนวทางในการระบุข้อบกพร่องและสถาปัตยกรรมส่วนขยาย ตรวจสอบก่อนที่จะมีการใช้งาน

REST และ HATEOS เหมาะสมสำหรับปัญหาที่ออกแบบมาสำหรับ:

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

อย่างไรก็ตามควรสังเกตว่าเว็บและส่วนที่เหลือไม่จำเป็นต้องเหมาะสมสำหรับทุกปัญหา:

ส่วนขยายที่เสนอนั้นสามารถนำมาเปรียบเทียบกับ REST เพื่อดูว่าเหมาะสมกับสถาปัตยกรรมหรือไม่ หากไม่เป็นเช่นนั้นจะมีประสิทธิภาพมากกว่าในการเปลี่ยนเส้นทางการทำงานไปยังระบบที่ทำงานแบบขนานพร้อมกับรูปแบบสถาปัตยกรรมที่เหมาะสมกว่า

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

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

แต่จริงๆแล้วมีเหตุผลใดที่จะคิดว่า REST เป็นสถาปัตยกรรมที่ต้องการสำหรับโดเมนนี้หรือไม่? มีหลักฐานที่บอกว่า HATEOAS เป็นหลักการออกแบบที่มีประโยชน์สำหรับการสื่อสารระหว่างเครื่องจักรกับเครื่องหรือไม่?

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

In Presentation ของ Fielding ใน Adobe Experience Manager:

REST ไม่ใช่สถาปัตยกรรม!

ส่วนที่เหลือเป็นรูปแบบสถาปัตยกรรมซึ่งเป็นนามธรรมของสถาปัตยกรรมที่แตกต่างที่มีอยู่บนอินเทอร์เน็ต

REST เป็นการสะสมข้อ จำกัด ในการออกแบบเพื่อชักนำคุณสมบัติทางสถาปัตยกรรม

REST เป็น buzzword และทุกคนต้องการมี RESTful API ในความเป็นจริงเมื่อผู้คนต้องเผชิญกับข้อ จำกัด ของ REST พวกเขาลดข้อ จำกัด เหล่านี้ลงเพราะไม่มีความต้องการหรือไม่มีประโยชน์ที่จะได้รับสำหรับพวกเขาที่จะใช้ข้อ จำกัด ทั้งหมด

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

ส่วนที่เหลือใน AEM

หากสิ่งที่คุณต้องการคือการสร้างบริการที่ใช้โดยเซิร์ฟเวอร์อื่นแล้ว xmlrpc เป็นตัวเลือกที่ถูกต้อง หากสิ่งที่คุณต้องการคือบริการที่ลูกค้าบางรายหรืออุปกรณ์ที่ใช้พลังงานต่ำหรือไคลเอนต์ที่ไม่รู้จักผ่านทางอินเทอร์เน็ตอาจพิจารณาใช้ json แต่จำไว้ว่า json เป็นสัญลักษณ์ที่ด้อยกว่าสำหรับการระบุข้อมูลทั่วไปเมื่อเทียบกับ xml