อะไรคือสิ่งสำคัญในปัจจุบันของสบู่

ครั้งล่าสุดที่ฉันพบบริการที่ใช้ SOAP คือในระหว่างการฝึกงานใน บริษัท การเงินในปี 2556 นั่นคือช่วงเวลาที่ฉันเริ่มต้นทำงานด้านไอที ฉันจำได้ว่ามีสื่อการเรียนรู้เกี่ยวกับสบู่ในหลักสูตรวิศวกรรมศาสตร์ของฉัน นอกเหนือจากนั้นฉันไม่ได้ใช้ SOAP มากในช่วงอาชีพของฉัน

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

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

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

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

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

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

แต่ไม่มีสิ่งใดที่เกี่ยวข้องกับ REST มากนัก

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

REST นั้นมีข้อ จำกัด มากกว่า SOAP ซึ่งเป็นจุดแข็งและเหตุผลของความนิยม

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

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

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

คุณไม่สามารถเปรียบเทียบ REST และ SOAP REST เป็นสถาปัตยกรรมในขณะที่ SOAP เป็นโปรโตคอล

น่าเสียดายที่ REST กลายเป็นคำพูดที่ใช้คำพ้องกับบริการ RESTful HTTP ซึ่งหมายถึงการสร้างสถาปัตยกรรมสไตล์ REST ด้วยโปรโตคอล HTTP เป็น (แอปพลิเคชั่น)

ส่วนที่เหลือจะขึ้นอยู่กับหลักการดังต่อไปนี้ (ข้อ จำกัด และองค์ประกอบ) (ในวงเล็บสำนึกใน HTTP สงบ) [1]

• ไร้สัญชาติ (HTTP เป็นโปรโตคอลไร้สัญชาติ)
• ทรัพยากร (ระบุโดย URIs)
• ชุดอินเตอร์เฟส (วิธี HTTP)
• การเป็นตัวแทน (MIME-TYPE)
• HATEOS (ไฮเปอร์ลิงก์)
• แคช (แคช HTTP)

ในด้านอื่น ๆ หลายคนหมายถึงโดยกล่าวว่า SOAP บริการเว็บบนพื้นฐานของ WSDL และสบู่ซึ่งเป็นส่วนหนึ่งของสถาปัตยกรรมบริการเว็บ W3C [2]

• SOAP ใช้เป็นโปรโตคอลในการแลกเปลี่ยนข้อมูล (โดยทั่วไปคือชื่อเมธอด, พารามิเตอร์, ค่าส่งคืน, ชนิดข้อมูล, ... )
• WSDL ภาษานิยามอินเตอร์เฟสเพื่ออธิบายเว็บเซอร์วิส

SOAP * ปัจจุบันมีความสำคัญอย่างไร

SOAP เป็นมาตรฐาน W3C และใช้เป็นรูปแบบการแลกเปลี่ยนข้อมูลในบริการเว็บ W3C บริการเว็บเหล่านั้น - โดยเฉพาะอย่างยิ่งในช่วง hype ของ SOA (บริการที่มุ่งเน้นการบริการ) ประมาณ 2008 (+ - 3 ปี) - และ (น่าเสียดายที่) ยังคงมีการนำไปใช้ในแอปพลิเคชันขององค์กรเป็นส่วนใหญ่

เรื่องนี้มีสาเหตุหลายประการ ก่อนหน้านั้น RESTful HTTP นั้นไม่เป็นที่รู้จักและมันก็เข้าใจผิด น่าเสียดายที่มันยังคงเข้าใจผิดว่าลองดูคำตอบอื่น ๆ

„ [... ] REST จำกัด มากกว่า SOAP [... ] "

„ วัตถุประสงค์หลักของ REST คือการแสดงทรัพยากรบนอินเทอร์เน็ต [... ] "

นอกจากนี้ SOAP (และ WSDL) เป็นส่วนหนึ่งของสแต็คโพรโทคอลบริการเว็บ W3C ซึ่งให้มาตรฐานที่มากยิ่งขึ้นสำหรับการใช้งานเว็บเซอร์วิส

ผู้คนยังคงพัฒนา API ที่ใช้ SOAP ใหม่หรือไม่

ดังนั้นใช่ยังมีอยู่และจะมีในอนาคตด้วยเช่นกันซึ่งกำลังใช้ SOAP (อย่างน้อยในระบบขององค์กรซึ่งส่วนใหญ่อยู่หลังประตู) แต่ส่วนใหญ่พยายามทำ "REST" บางชนิดในปัจจุบัน

ใครสามารถโปรดแก้ไขให้ฉันถ้าฉันผิดเกี่ยวกับความแตกต่างระหว่าง SOAP และ REST นี้

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

อย่างที่ฉันเขียนไปแล้วคุณไม่สามารถเปรียบเทียบได้ แต่คุณสามารถเปรียบเทียบ RESTful HTTP Web Service กับ SOAP / WSDL Web Service