WSDL vs REST ข้อดีและข้อเสีย

ที่เกี่ยวข้อง:

เหตุใดจึงต้องใช้ REST แทนบริการบนเว็บ

เมื่อตัดสินใจว่าจะใช้บริการเว็บโดยใช้ SOAP หรือ REST (โดยที่ฉันหมายถึง HTTP / XML ในลักษณะ RESTful) ฉันควรระวังอะไรและควรคิดอย่างไร ฉันคิดว่านี่ไม่ใช่ขนาดเดียวที่เหมาะกับทุกสิ่งดังนั้นฉันจะเลือกใช้อย่างไร

โปรโตคอลทั้งสองมีการใช้งานที่แตกต่างกันมากในโลกแห่งความเป็นจริง

SOAP (ใช้ WSDL) เป็นมาตรฐาน XML ที่มีน้ำหนักมากซึ่งมีศูนย์กลางอยู่ที่การส่งผ่านเอกสาร ข้อดีคือคำขอและการตอบกลับของคุณมีโครงสร้างที่ดีมากและยังสามารถใช้ DTD ได้อีกด้วย ข้อเสียคือ XML และมีรายละเอียดมาก อย่างไรก็ตามนี่เป็นเรื่องดีหากสองฝ่ายจำเป็นต้องมีสัญญาที่เข้มงวด (พูดเพื่อการสื่อสารระหว่างธนาคาร) SOAP ยังช่วยให้คุณสามารถเลเยอร์สิ่งต่างๆเช่น WS-Security บนเอกสารของคุณ SOAP โดยทั่วไปไม่เชื่อเรื่องพระเจ้าในการขนส่งซึ่งหมายความว่าคุณไม่จำเป็นต้องใช้ HTTP

REST มีน้ำหนักเบามากและอาศัยมาตรฐาน HTTP ในการทำงาน เป็นเรื่องดีที่จะได้รับบริการเว็บที่มีประโยชน์และทำงานได้อย่างรวดเร็ว หากคุณไม่ต้องการคำจำกัดความ API ที่เข้มงวดนี่คือหนทางที่จะไป บริการเว็บส่วนใหญ่อยู่ในหมวดหมู่นี้ คุณสามารถกำหนดเวอร์ชัน API ของคุณเพื่อให้การอัปเดตไปยัง API ไม่ทำให้ API เสียหายสำหรับผู้ที่ใช้เวอร์ชันเก่า (ตราบใดที่พวกเขาระบุเวอร์ชัน) REST ต้องการ HTTP เป็นหลักและไม่เชื่อเรื่องพระเจ้าในรูปแบบ (หมายความว่าคุณสามารถใช้ XML, JSON, HTML อะไรก็ได้)

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

ลิงค์ต่อไปนี้ให้ข้อมูลที่เป็นประโยชน์เกี่ยวกับ WSDL vs REST รวมถึงข้อดีและข้อเสีย

ประเด็นสำคัญสองประการคือ

1) SOAP ได้รับการออกแบบมาสำหรับสภาพแวดล้อมการประมวลผลแบบกระจายโดย REST ได้รับการออกแบบมาสำหรับสภาพแวดล้อมแบบจุดต่อจุด

2) สามารถใช้ WADL เพื่อกำหนดอินเทอร์เฟซสำหรับบริการ REST

http://www.ajaxonomy.com/2008/xml/web-services-part-1-soap-vs-rest
http://ajaxonomy.com/2008/xml/web-services-part-2-wsdl-and -wadl

เกี่ยวกับ WSDL (หมายถึง "SOAP") ว่า "มีน้ำหนักมาก" เรื่องหนักยังไง หากชุดเครื่องมือทำ "การยกของหนัก" ทั้งหมดให้คุณแล้วทำไมมันถึงสำคัญ?

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

แม้ว่าจะเสร็จสิ้นทั้งหมดแล้วคุณก็ยังต้องแปลเอกสารที่มนุษย์อ่านได้เป็นรหัสโดยที่ผู้ดูแลทั้งหมดมีความเสี่ยงที่มนุษย์จะอ่านผิด เนื่องจาก WSDL เป็นคำอธิบายบริการที่เครื่องอ่านได้จึง "อ่านผิด" ได้ยากกว่ามาก

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

นี่อาจเป็นความคิดเห็นในหลาย ๆ โพสต์ด้านบน แต่ฉันยังไม่มีตัวแทนที่จะทำเช่นนั้นต่อไปนี้

ฉันคิดว่าเป็นเรื่องน่าสนใจที่ข้อดีและข้อเสียจำนวนมากที่มักอ้างถึง SOAP และ REST มี (IMO) น้อยมากที่จะเกี่ยวข้องกับค่าหรือขีด จำกัด ที่แท้จริงของเทคโนโลยีทั้งสอง อาจเป็นโปรที่ถูกอ้างถึงมากที่สุดสำหรับ REST คือ "น้ำหนักเบา" หรือมีแนวโน้มที่จะ "มนุษย์อ่านได้" มากกว่า ในระดับหนึ่งสิ่งนี้เป็นความจริงอย่างแน่นอน REST มีอุปสรรคในการเข้าต่ำกว่า - มีโครงสร้างที่ต้องการน้อยกว่า SOAP (แม้ว่าฉันจะเห็นด้วยกับผู้ที่กล่าวว่าการใช้เครื่องมือที่ดีนั้นส่วนใหญ่เป็นคำตอบที่นี่ - เครื่องมือ SOAP ที่แย่เกินไปคือ ค่อนข้างน่ากลัว)

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

ดังนั้นเพื่อใช้ในการแลกเปลี่ยนข้อมูลที่มีโครงสร้างระหว่างระบบคอมพิวเตอร์ฉันไม่แน่ใจว่า REST นั้นดีกว่า SOAP (หรือวีซ่าในทางกลับกัน) แต่ก็แตกต่างกัน ฉันคิดว่าการเปรียบเทียบด้านบนของ REST กับ SOAP กับการพิมพ์แบบไดนามิกและแบบคงที่นั้นดี ในกรณีที่ภาษา dyanmic มักจะประสบปัญหาคือการบำรุงรักษาในระยะยาวและการบำรุงรักษาระบบ (และในระยะยาวฉันไม่ได้พูดถึงปีหรือ 2 ปีฉันกำลังพูดถึง 5 หรือ 10) มันจะน่าสนใจที่จะดูว่า REST พบกับความท้าทายเดียวกันหรือไม่เมื่อเวลาผ่านไป ฉันมักจะคิดว่ามันจะเป็นเช่นนั้นหากฉันสร้างระบบประมวลผลข้อมูลแบบกระจายฉันจะโน้มน้าวให้ SOAP เป็นกลไกการสื่อสาร (เนื่องจากการแบ่งชั้นของโปรโตคอลการถ่ายโอนและแอปพลิเคชันและความยืดหยุ่นที่ให้ไว้ตามที่ได้กล่าวไว้ข้างต้น)

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

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

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

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

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

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

สำหรับฉันบริการ REST เกือบจะเหมือนกับว่าคุณจะสร้าง servlet แทนบริการเว็บ SOAP servlet รับข้อมูลเข้าและส่งคืนข้อมูลออก รูปแบบของข้อมูลขึ้นอยู่กับ xml นอกจากนี้เรายังสามารถจินตนาการว่าจะใช้อย่างอื่นที่ไม่ใช่ xml หากเราต้องการ สำหรับแท็กอินสแตนซ์สามารถใช้แทน xml และนั่นจะไม่ใช่ REST อีกต่อไป แต่เป็นอย่างอื่น (อาจมีน้ำหนักเบากว่าเนื่องจาก xml ไม่ใช่แสงตามธรรมชาติ) เราจะเรียกว่ายังคงเป็นบริการเว็บหรือไม่? ใช่เราทำได้ แต่นั่นจะไม่เป็นไปตามมาตรฐานปัจจุบันใด ๆ และนี่คือปัญหาหลักที่นี่หากเราเริ่มเรียกใช้บริการเว็บทุกอย่าง แต่เราสามารถทำได้ในแบบที่เราต้องการจากนั้นเราก็สูญเสียความสามารถในการทำงานร่วมกันของสิ่งต่างๆ นั่นหมายความว่ารูปแบบของข้อมูลที่แลกเปลี่ยนกับบริการเว็บไม่ได้มาตรฐานอีกต่อไป

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

SOAP : สามารถขนส่งผ่าน SMTP ได้เช่นกันหมายความว่าเราสามารถเรียกใช้บริการโดยใช้รูปแบบข้อความอีเมลง่ายๆได้เช่นกัน

ต้องการเฟรมเวิร์ก / เอ็นจิ้นเพิ่มเติมควรอยู่ในเครื่องผู้ใช้บริการเว็บเพื่อแปลงข้อความ SOAP เป็นโครงสร้างอ็อบเจ็กต์ตามลำดับในภาษาต่างๆ

REST : ตอนนี้ WSDL2.0 รองรับการอธิบายบริการเว็บ REST ด้วย

เราสามารถใช้เมื่อคุณต้องการให้บริการของคุณมีน้ำหนักเบาเช่นโทรจากอุปกรณ์พกพาเช่นโทรศัพท์มือถือ PDA เป็นต้น ...

สำหรับระบบองค์กรที่ระบบของคุณถูก จำกัด ไว้ภายใน บริษัท ของคุณการใช้สบู่นั้นง่ายและเหมาะสมกว่าเพราะคุณเกือบจะเป็นผู้ควบคุมลูกค้า มันง่ายกว่าเนื่องจากมีเครื่องมือมากมายที่สร้างคลาส (พร็อกซี) และดูเหมือนว่าคุณกำลังทำ OOP ปกติของคุณซึ่งตรงกับสภาพแวดล้อม java หรือ. net ของคุณ (ซึ่ง บริษัท ส่วนใหญ่ใช้)

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

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

สำหรับแอปพลิเคชันระดับองค์กรฉันคิดว่า REST ไม่เพียงพอเนื่องจากธุรกรรมความปลอดภัยการพิมพ์ที่เข้มงวดสกีมามีความสำคัญมากในการพัฒนาแอปพลิเคชันขององค์กรนั่นคือเหตุผลที่ SOAP เหมาะสำหรับพวกเขามากกว่า

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

ขอโทษสำหรับภาษาอังกฤษที่ไม่ดีของฉัน

ในการป้องกัน REST นั้นเป็นไปตามหลักการของ HTTP และความสามารถในการระบุแอดเดรสอย่างใกล้ชิดเช่นการดำเนินการอ่านใช้ GET การอัปเดตการดำเนินการใช้ POST เป็นต้นฉันพบว่านี่เป็นวิธีที่สะอาดกว่ามาก หนังสือ Oreilly RESTful Web Services อธิบายสิ่งนี้ได้ดีกว่าที่ฉันทำได้ถ้าคุณอ่านฉันคิดว่าคุณน่าจะชอบแนวทาง REST

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

หากคุณต้องการเลือกฉันขอแนะนำ REST จะง่ายกว่า

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

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

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

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

คุณสามารถเปลี่ยนองค์ประกอบเว็บ WSDL-spewing WCF ไปเป็นการใช้งานอื่น ๆ ได้อย่างง่ายดายเพียงแค่เปลี่ยนการตั้งค่าการกำหนดค่าของคุณ คุณสามารถข้าม HTTP แล้วตั้งชื่อไปป์, tcp, โปรโตคอลที่กำหนดเอง ฯลฯ โดยไม่ต้องเปลี่ยนรหัสของคุณ ฉันเชื่อว่าส่วนประกอบ WCF อาจง่ายกว่าในการตั้งค่าสำหรับสิ่งต่างๆเช่นความปลอดภัยการโทรสองทางธุรกรรมการทำงานพร้อมกัน ฯลฯ

REST จำกัด คุณไว้ที่ HTTP (ซึ่งใช้ได้ดีในหลาย ๆ กรณี)

ฉันรู้ว่าการสนทนานี้เป็นเรื่องเก่า แต่หลังจากอ่านคำตอบและแสดงความคิดเห็นทั้งหมดฉันเชื่อว่าทุกคนพลาดประเด็นสำคัญที่สุดเกี่ยวกับความแตกต่างระหว่าง 2 ระบบ: SOAP ใช้ประเภทที่ซับซ้อนเพื่อไม่เพียง แต่ให้ข้อมูลแก่คุณเท่านั้น แต่ยังตรวจสอบความถูกต้อง และเก็บไว้ในการกำหนดประเภทที่เข้มงวดซึ่งกำหนดไว้สำหรับ WSDL จะบอกคุณว่ารูปแบบข้อมูลคืออะไรประเภทข้อมูลคืออะไรช่วยให้คุณสามารถเพิ่มกฎรูปแบบรูปแบบ reg-ex และกำหนดจำนวนครั้งของข้อมูลที่ต้องมีและอาจได้รับอนุญาตในคำขอ / การตอบกลับ . ในทางกลับกันไม่มีกลไกเหล่านี้

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

SOAP เป็นธุรกิจที่เป็นอิสระเนื่องจากมีกฎข้อมูลทั้งหมดที่ฝังอยู่ในเอกสาร

ความแตกต่างระหว่าง SOAP และ REST คือ SOAP เป็นสคีมาที่มุ่งเน้นธุรกิจในตัวเอง REST เป็นเอกสารข้อความ