เท่าที่ฉันเห็นการบริโภค SOAP ต้องใช้ SOAP stack ดังนั้นจึงยากสำหรับลูกค้าของคุณที่จะใช้เช่นพวกเขาต้องการให้แน่ใจว่าพวกเขามี SOAP stack ในสถานที่ที่จัดรูปแบบข้อมูล POST และส่วนหัวได้อย่างถูกต้อง โครงสร้างข้อมูลในขณะที่ REST คุณเพียงแค่ร้องขอ HTTP GET พร้อมอาร์กิวเมนต์ในสตริงการสืบค้นและรับข้อความที่ฉันคิดว่าน่าจะเป็น XML กลับมา
ดังนั้นค่าใช้จ่ายพิเศษ / ความซับซ้อนของ SOAP ให้อะไรคุณเมื่อไหร่ที่คุณต้องการและเมื่อไหร่ที่คุณและคุณควรจะทำโดยไม่ต้องทำ?
คำตอบ:
ฉันเคยใช้ REST API มาก่อนและฉันชอบมันมาก โดยทั่วไปเมื่อคุณใช้RESTผ่าน SOAP ไคลเอนต์ / เซิร์ฟเวอร์ของคุณจะมีความหมายมากกว่าเดิมซึ่งคุณสามารถเปลี่ยนเซิร์ฟเวอร์ได้อย่างอิสระมากขึ้นโดยไม่กระทบกับลูกค้าของคุณ orthogonality นี้เกิดจากการใช้การสื่อสารที่เป็นนามธรรมและกำหนดไว้แล้วอย่างดีผ่านทางกริยา HTTP นอกจากนี้การใช้ไฮเปอร์ลิงก์ที่ฝังอยู่ในการตอบกลับของคุณทำให้ง่ายต่อการขยายและเติบโต API ของคุณโดยไม่เจ็บปวด ลูกค้าควรติดตามลิงก์ที่ฝังอยู่เหล่านี้เพื่อไปยังแหล่งข้อมูลใหม่ ๆ เช่นมนุษย์จะติดตามลิงก์ในหน้าเว็บเพื่อ 'เจาะลึก' เพื่อดูข้อมูลเพิ่มเติม
ด้วยที่กล่าวว่าฉันมีเพื่อนร่วมงานบางคนที่บอกว่าพวกเขาต้องใช้สบู่และพวกเขาบ่นเกี่ยวกับมันตลอดเวลา ดังนั้นฉันจึงทำการค้นคว้ารายละเอียดทั้งสองเพิ่มเติมอีกเล็กน้อย
โดยทั่วไปสิ่งที่ผมพบคือว่าที่เหลือเป็นเหมาะสำหรับการใช้งานกระจายสูงเมื่อคุณมีหลายร้อยหลายพันหรือล้านของลูกค้า เหตุผลหนึ่งคือ orthogonality ดังกล่าวข้างต้นอีกเหตุผลหนึ่งคือการแคชที่คุณได้รับฟรีเนื่องจากคุณใช้ HTTP
SOAP อาจเป็นวิธีที่รวดเร็วกว่าเมื่อคุณต้องการ API ที่เล็กกว่าสำหรับลูกค้าหรือสองคนได้อย่างรวดเร็วและคุณไม่ต้องกังวลเกี่ยวกับความสามารถในการขยาย มันอาจเหมาะกับคุณดีกว่าถ้าคุณไม่มีสถาปัตยกรรมที่มีโครงสร้างรอบทรัพยากรเพราะอาจใช้เวลาพอสมควรในการปรับโครงสร้างแอปของคุณเพื่อให้สามารถใช้งาน REST ได้
อาจเป็นจุดรอง แต่ส่วนที่เหลือจะยึดตาม HTTP ทั้งหมด
SOAP ไม่จำเป็นต้องใช้ HTTP และคุณสามารถใช้การขนส่งใดก็ได้ที่คุณต้องการ
ข้อความ SOAP สามารถกำหนดเส้นทางแบบอะซิงโครนัสและเชื่อถือได้ในขณะที่ส่วนที่เหลือเป็นกระบวนทัศน์แบบซิงโครนัส
REST ไม่ได้บอกอะไรคุณเกี่ยวกับข้อมูลที่คุณกำลังส่งและรับ มี WADL แต่ส่วนใหญ่คุณพึ่งพาเอกสารของ API ว่าถูกต้องหรือไม่ SOAP มี Circus ของเทคโนโลยี XML เพื่อทำให้คำอธิบายข้อมูลมีข้อผิดพลาดน้อยลง WSDL, Schema ...
ในตอนท้ายของวัน REST นั้นจะทำให้คุณมีระบบไฟล์ตาม HTTP หากระบบของคุณสามารถปรับให้เข้ากับกระบวนทัศน์นั้นได้อาจเป็นทางเลือกที่ดี
ดังนั้นค่าใช้จ่ายพิเศษ / ความซับซ้อนของ SOAP ให้อะไรคุณเมื่อไหร่ที่คุณต้องการและเมื่อไหร่ที่คุณและคุณควรจะทำโดยไม่ต้องทำ?
ความแตกต่างที่ใหญ่ที่สุดระหว่างสองคือส่วนที่เหลือคือคิดว่าจะเป็นคนไร้สัญชาติที่-สบู่ไม่ได้ ในทางปฏิบัติการใช้งาน REST จำนวนมากจะใช้สถานะบางอย่างในเซสชันผ่านทาง OAuth
แตกต่างก็คือส่วนที่เหลือเป็นอย่างมาก "ทรัพยากร" หรือเชิงรูปธรรม คุณโต้ตอบกับทรัพยากรผ่านการดำเนินการ CRUD อะไรก็ตามที่ไม่เหมาะกับกระบวนทัศน์นี้จะยุ่งยากและอึดอัดใจ
สบู่ในมืออื่น ๆ เป็นเพียง RPC (เรียกขั้นตอนระยะไกล) โปรโตคอล มันไม่ได้มาพร้อมกับกระบวนทัศน์มันเป็นเพียงชั้นการขนส่ง
REST ใช้โพสต์เช่นกัน ในความเป็นจริงเมื่อใช้ REST คำกริยา http จะบอกคุณว่าการดำเนินการเกิดขึ้น
REST และ SOAP เป็นเพียงมาตรฐานที่แตกต่างกันในการส่งผ่านข้อมูลทางอินเทอร์เน็ต
มีการใช้ทั้งฉันโดยทั่วไปฉันจะแนะนำให้ใช้ REST มากกว่า SOAP เว้นแต่คุณจะรู้ว่าคนที่จะใช้บริการเว็บของคุณใช้. net และ Visual Studio โดยทั่วไปจะง่ายกว่ามากในการใช้บริการเว็บ REST ยกเว้น. net VS ซึ่งทำงานส่วนใหญ่ให้คุณเมื่อคุณใช้ SOAP
สิ่งหนึ่งที่ฉันจะกล่าวถึงคือการทำงานร่วมกัน - ถ้าคุณจะโทรหาบริการของคุณจากแอปที่เขียนใน. NET และเซิร์ฟเวอร์จะเขียนด้วย Java (หรือชุดค่าผสมอื่น ๆ ) จากนั้นไปที่ REST ฉันเห็นความไม่ลงรอยกันเล็กน้อยมากเกินไประหว่างการใช้ SOAP เพื่อรบกวนการพิจารณาอีกต่อไป
หากคุณต้องการคำแนะนำง่ายๆที่มองเห็นได้เพื่อช่วยคุณวัด SOAP และ REST กับความต้องการของแอปพลิเคชันของคุณ ...
Vijay Prasad Gupta ได้รวบรวมแผนภูมิการไหลที่เรียบง่ายและเป็นประโยชน์
ลิงก์โดยตรงไปยังแผนภูมิการไหล: https://drive.google.com/file/d/0B3zMtAq1Rf-sdVFNdThvNmZWRGc/edit
ลิงก์ไปที่บทความ: https://www.linkedin.com/pulse/20140818062318-7933571-soap-vs-rest-flowchart-to-determine-the-right-web-services-protocol-for-your-nour
ตอนนี้เป็นปี 2558 ฉันหวังว่า SOAP จะตายไปแล้ว แต่มันก็ยังคงเหมือนกลิ่นเหม็น ไม่ว่าจะเป็นอะไรก็ตามนอกจากแอปพลิเคชั่น "ตัวอย่าง" พื้นฐานที่สุดการรวมเข้ากับบริการ SOAP นั้นเต็มไปด้วยความท้าทาย มันเป็นสถาปัตยกรรมที่ซับซ้อนที่มีตัวเลือกมากมายในหลายระดับรวมกับนิสัยใจคอของการใช้งานที่หลากหลายและความเข้ากันไม่ได้ (ไม่บอบบาง) ฉันไม่เคยมีประสบการณ์ที่ดีเลย REST ตรงกันข้ามเป็นเรื่องง่าย: ทุกคนเข้าใจ HTTP สำหรับกรณีส่วนใหญ่ JSON มีประโยชน์มากกว่า XML InfoSet
เพื่อให้แนวคิดเกี่ยวกับความซับซ้อนของ SOAP ให้ลองรวบรวม SOAP library เข้ากับโครงการของคุณ สำหรับ Java ไคลเอ็นต์ Apache Axis2 พื้นฐานที่สุด (โดยใช้การเชื่อมโยงข้อมูล ADB แบบง่าย) จะดึง JAR ใหม่ 23 ตัว ยี่สิบสาม! ห้องสมุดขยายตัว 20MB CXF คล้ายกัน: 21 ขวดเมื่อฉันนับครั้งสุดท้าย
หากคุณต้องการจริงๆคุณสามารถทำ REST ด้วยไลบรารี HTTP แบบง่าย