ฉันควรใช้ WADL เพื่ออธิบาย RESTful API ของฉันหรือไม่

27

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

ฉันต้องการตรวจสอบให้แน่ใจว่าฉันได้ให้คำอธิบายของจุดสิ้นสุดของฉันในลักษณะที่จะอนุญาตให้แอปพลิเคชันไคลเอนต์ถูกสร้างขึ้นโดยอัตโนมัติในภาษาที่หลากหลาย ฉันเข้าใจว่าสำหรับบริการบนเว็บของ SOAP ฉันสามารถใช้ WSDL และเห็นได้ชัดว่ามี WSDL2 ที่ให้คำจำกัดความของคำกริยา HTTP ที่ใช้กับ REST ได้ดีขึ้น อย่างไรก็ตามฉันเห็นหลายบทความที่แกว่งไปมาเป็นประโยชน์

ดังนั้นฉันควรใช้WADLเพื่ออนุญาตให้ผู้สร้างรหัสภายนอกสร้างไคลเอนต์สำหรับเว็บแอปพลิเคชันของฉันได้อย่างรวดเร็วหรือมีมาตรฐานที่ดีกว่าที่คาดไว้หรือไม่

web-applications rest standards

— Gary Rowe
แหล่งที่มา

1

ว้าว - 2 วันและเพียงแค่เงียบสงบทำให้เกิดเสียงกรอบแกรบของลมผ่าน tumbleweeds และ ...

— แกรี่ Rowe

ไม่ได้อย่างแน่นอน. WADLs อาจเป็นเครื่องมือ API ที่แย่ที่สุดที่ฉันเคยพบมา

— TheCodingArt

18

คำแนะนำของฉันคือไม่รบกวน WADL ไม่ได้นำมาใช้อย่างกว้างขวางดูคำถามนี้ใน Stack Overflowและมีมุมมองที่แข็งแกร่งบางประการที่ไม่เหมาะสมกับ REST แบบ 'เหมาะสม' ที่คุณอธิบายดังที่แสดงไว้ที่นี่ในคำถาม Stack Overflowอื่น

คำอธิบาย WADL ใช้เวลานานในการสร้าง (และส่วนใหญ่เป็นคู่มือ) และเพิ่มความเปราะบางที่ HATEOAS ได้รับการออกแบบมาเพื่อหลีกเลี่ยง - นั่นคือคุณจะมีจุดเข้าใช้ที่กำหนดไว้อย่างชัดเจน 'สัญญา'.

ไม่ได้หมายความว่าคุณควรหนีจากเอกสารคำจำกัดความของสคีมา ฯลฯ แม้ว่าจะมีการสิ้นสุดของ RESTifarian สเปกตรัมที่จะแนะนำให้คุณเข้าใกล้คำอธิบายตัวเองในระดับสูงที่คุณไม่ต้องการ ฉันไม่พบสิ่งนี้ในทางปฏิบัติ ตัวอย่างการทำงานที่มั่นคงบางอย่างควรเป็นความต้องการของผู้พัฒนาที่ไม่คุ้นเคย และทำให้ลูกค้าสองสามรายใช้ API ของคุณเองเพื่อทดลองใช้ (ง่ายพอจาก JQuery) นั่นจะช่วยให้คุณมีข้อบ่งชี้ที่ดีว่าคุณกำลังสร้างสิ่งที่บริโภคได้หรือไม่

เป็นแหล่งที่ดีของข้อมูลในพื้นที่นี้เป็นHypertext ประยุกต์ใช้ภาษา ฉันพบว่ามันมีน้ำหนักน้อย แต่การโต้วาทีในรายชื่อผู้รับจดหมายนั้นดีและเป็นปัจจุบันและมีความเกี่ยวข้อง

หวังว่าจะช่วยให้คุณเริ่มต้น

— จูเลียนบราวน์
แหล่งที่มา

2

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

— Gary Rowe

5

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

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

ถึงกระนั้นก็มีคนบอกว่าเพื่อนร่วมงานของฉันใช้เวลาหลายเดือนในการทำงานกับไลบรารีที่ใช้ส่วนต่อประสาน REST กับบริการและส่วนต่อประสานที่อธิบาย WSDL ไปยังบริการเดียวกัน^[*]ได้รับการออกแบบโดยอัตโนมัติเกือบคุณภาพเดียวกันในไม่กี่วินาที ส่วนที่เหลือของวิธีการที่เกี่ยวกับวันของการเขียนชั้นเรียนห่อ ลางสังหรณ์ของฉัน (ตามขนาดตัวอย่างที่ จำกัด ) คือคุณไม่สามารถกำจัดความเปราะบางทั้งหมดในบริการที่ซับซ้อนได้เพราะความหมายของบริการจะพัฒนาอย่างหลีกเลี่ยงไม่ได้ตลอดเวลาและ REST นั้นดีกว่าในการขับขี่อินเตอร์เฟสสำหรับมนุษย์ในขณะที่ SOAP ดีกว่า อินเตอร์เฟสไลบรารี (มีเครื่องมือไคลเอ็นต์ WSDL / SOAP ที่ดีสำหรับเกือบทุกภาษาของบันทึกย่อ) นอกจากว่าคุณจะมีความหรูหราในการทำทั้งสองอย่างสิ่งที่จะให้ความสำคัญควรขึ้นอยู่กับกลุ่มลูกค้าที่คุณใส่ใจมากที่สุด

ฉันจะไม่ใช้ความพยายามมากใน WADL แต่ถ้ากรอบงาน REST ของคุณจะสร้างให้คุณ (Apache CXF ทำสิ่งนี้) ก็ไม่มีเหตุผลใดที่จะไม่ให้มัน ใครก็ตามที่ต้องการตัดรหัสของคุณจะต้องมี WSDL + SOAP

^{[*] ในฐานะผู้ให้บริการที่มีปัญหาฉันสามารถพูดได้ว่าอินเตอร์เฟซทั้งสองรองรับการทำงานเดียวกัน - มีโมเดลนามธรรมพื้นฐานทั่วไปและในสไตล์ "ธรรมชาติ" สำหรับทั้งสองประเภทอินเตอร์เฟส ในด้านการบริการมันเป็นกรณีที่แน่นอนว่าบางสิ่งง่ายขึ้นกับ REST และอื่น ๆ ด้วย SOAP}

— Donal Fellows
แหล่งที่มา

+1 บริษัท ของฉันและญาติของมันอยู่ในช่วงเวลาที่ว่า "ใครต้องการสบู่เรามีส่วนที่เหลือ!" เราสร้างwrapper REST แบบง่ายๆ รอบ ๆ บริการสบู่ของเรา ไม่ใช่ว่าทุกอย่างจะง่ายหรือชัดเจน บางครั้งมันยากและซับซ้อน ดังนั้นเราจึงนำเสนอบุคคลที่สามด้วยส่วนต่อประสาน REST ที่กำหนดเขตข้อมูลจำนวนหนึ่งที่พวกเขาสนใจสิ่งนี้จะห่อหุ้มบริการ SOAP โดยมีเอกสารอินพุตและเอาท์พุตที่ซับซ้อน เราใช้บริการ WCF "dual interface" ซึ่งทั้ง SOAP และ REST endpoint ถูกสร้างขึ้นจากรหัส (สร้างจาก Xsd Schema ที่เขียนด้วย XmlSpy)

— RoboJ1M

2

W3Cได้ทำข้อเสนอแนะอย่างเป็นทางการสำหรับมาตรฐานเอกสารส่วนที่เหลือขึ้นอยู่กับWSDL 2.0 นี่คือคำพูดจากบทความ IBM :

โดยทั่วไปคำว่าเว็บเซอร์วิสจะเกี่ยวข้องกับการบริการหรือการดำเนินการโดยใช้ SOAP และมาตรฐาน WS * เช่น WS-Addressing และ WS-Security คำว่าบริการเว็บ REST โดยทั่วไปหมายถึงสถาปัตยกรรมบริการบนเว็บที่ใช้ทรัพยากรที่ใช้ HTTP และ XML รูปแบบการบริการเว็บสถาปัตยกรรมเหล่านี้แต่ละแบบมีอยู่ แต่จนกระทั่งเมื่อไม่นานมานี้มาตรฐาน WSDL ไม่สนับสนุนทั้งสองสไตล์เท่ากัน การโยง WSDL 1.1 HTTP ไม่เพียงพอที่จะอธิบายการสื่อสารกับ HTTP และ XML ดังนั้นจึงไม่มีวิธีที่จะอธิบาย REST Web services อย่างเป็นทางการด้วย WSDL สิ่งพิมพ์ของ WSDL 2.0 ซึ่งได้รับการออกแบบโดยคำนึงถึงบริการของ REST เป็นคำแนะนำของ World Wide Web Consortium (W3C) หมายความว่าขณะนี้มีภาษาที่ใช้อธิบายการบริการของ REST ทางเว็บ

— chaotic3quilibrium
แหล่งที่มา

บทความนั้นเขียนขึ้นในปี 2008 ในขณะที่ WADL เองก็ถูกส่งในปี 2009 เท่านั้นดังนั้นจึงยังห่างไกลจากคำแนะนำที่เป็นธรรม ตอนนี้ฉันอยากรู้ว่าสถานะคืออะไรในปี 2017 10 ปีหลังจากคำแนะนำ W3C WSDL 2.0 ... WSDL เวอร์ชันล่าสุดวันนี้ยังคงเหมือนเดิม WSDL 2007 2007 ไม่ใช่ความคืบหน้าเดียว (เทียบกับพูด HTML และ HTTP) ฉันสงสัยว่าเป็นสิ่งที่ดีหรือไม่?

— Hendy Irawan