สบู่กับส่วนที่เหลือ (ความแตกต่าง)

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

1. REST เป็นแบบไดนามิกมากขึ้นไม่จำเป็นต้องสร้างและอัปเดต UDDI (Universal Description, Discovery, and Integration)

2. REST ไม่ได้ถูก จำกัด รูปแบบ XML เท่านั้น บริการเว็บสงบสามารถส่งข้อความธรรมดา / JSON / XML

แต่ SOAP นั้นได้มาตรฐานมากกว่า (เช่นความปลอดภัย)

ดังนั้นฉันถูกต้องในจุดเหล่านี้หรือไม่

น่าเสียดายที่มีข้อมูลที่เข้าใจผิดและความเข้าใจผิดจำนวนมากรอบ REST ไม่เพียง แต่คำถามและคำตอบของ @cmdของคุณเท่านั้น แต่ยังรวมถึงคำถามและคำตอบส่วนใหญ่ที่เกี่ยวข้องกับหัวเรื่องใน Stack Overflow

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

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

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

ฉันคิดว่าสิ่งเหล่านี้เป็นจุดสำคัญในการทำความเข้าใจเกี่ยวกับ REST และแตกต่างจาก SOAP อย่างไร:

• REST เป็นโปรโตคอลอิสระ มันไม่ได้เชื่อมต่อกับ HTTP เหมือนกับที่คุณสามารถติดตามลิงก์ ftp บนเว็บไซต์แอปพลิเคชัน REST สามารถใช้โปรโตคอลใด ๆ ที่มีรูปแบบ URI ที่เป็นมาตรฐาน

• REST ไม่ใช่การแม็พ CRUD กับเมธอด HTTP อ่านคำตอบนี้สำหรับคำอธิบายโดยละเอียดเกี่ยวกับสิ่งนั้น

• ส่วนที่เหลือเป็นมาตรฐานเช่นเดียวกับชิ้นส่วนที่คุณใช้ ความปลอดภัยและการรับรองความถูกต้องใน HTTP นั้นเป็นมาตรฐานดังนั้นนั่นคือสิ่งที่คุณใช้เมื่อทำ REST ผ่าน HTTP

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

• REST เป็นรูปแบบสถาปัตยกรรมของเว็บเอง เมื่อคุณป้อนสแต็คโอเวอร์โฟลว์คุณจะรู้ว่าผู้ใช้คำถามและคำตอบคืออะไรคุณรู้ประเภทสื่อและเว็บไซต์มีลิงก์ไปยังพวกเขา REST API ต้องทำเช่นเดียวกัน ถ้าเราได้รับการออกแบบเว็บวิธีที่ผู้คนคิดว่าส่วนที่เหลือควรจะทำแทนการมีหน้าบ้านที่มีการเชื่อมโยงไปคำถามและคำตอบที่เราต้องการมีเอกสารคงอธิบายว่าเพื่อที่จะดูคำถามคุณต้องใช้ URI stackoverflow.com/questions/<id>, แทนที่ id ด้วย Question.id และวางลงบนเบราว์เซอร์ของคุณ นั่นเป็นเรื่องไร้สาระ แต่นั่นคือสิ่งที่หลายคนคิดว่า REST

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

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

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

RESTเทียบSOAPเป็นไม่ได้คำถามที่เหมาะสมที่จะถาม

RESTซึ่งแตกต่างSOAPคือไม่โปรโตคอล

RESTเป็นรูปแบบสถาปัตยกรรมและการออกแบบสำหรับสถาปัตยกรรมซอฟต์แวร์ที่ใช้เครือข่าย

RESTแนวคิดจะเรียกว่าทรัพยากร การเป็นตัวแทนของทรัพยากรจะต้องไร้สัญชาติ มันถูกแสดงผ่านสื่อบางประเภท ตัวอย่างบางส่วนของสื่อประเภท ได้แก่XML, และJSON RDFทรัพยากรถูกควบคุมโดยส่วนประกอบ คอมโพเนนต์ร้องขอและจัดการทรัพยากรผ่านอินเทอร์เฟซแบบมาตรฐาน ในกรณีของ HTTP ที่อินเตอร์เฟซนี้ประกอบด้วย Ops HTTP มาตรฐานเช่นGET, PUT, ,POSTDELETE

@ คำถามของ Abdulaziz จะอธิบายความจริงที่ว่าRESTและHTTPมักจะใช้ควบคู่ สาเหตุหลักมาจากความเรียบง่ายของ HTTP และการจับคู่ที่เป็นธรรมชาติกับหลักการ RESTful

หลักการ REST พื้นฐาน

การสื่อสารกับไคลเอนต์ - เซิร์ฟเวอร์

สถาปัตยกรรมไคลเอนต์ - เซิร์ฟเวอร์มีการแยกความกังวลอย่างชัดเจน แอ็พพลิเคชันทั้งหมดที่สร้างในสไตล์ RESTful ต้องเป็นไคลเอ็นต์ - เซิร์ฟเวอร์ในหลักการ

ไร้สัญชาติ

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

แคชได้

อาจมีการใช้ข้อ จำกัด แคชจึงทำให้สามารถทำเครื่องหมายข้อมูลการตอบสนองเป็นแคชหรือไม่แคชได้ ข้อมูลใด ๆ ที่ทำเครื่องหมายเป็นแคชสามารถนำมาใช้ใหม่เป็นการตอบสนองต่อคำขอที่ตามมาเหมือนกัน

ชุดอินเตอร์เฟส

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

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

ดูโพสต์บล็อกนี้ในหลักการออกแบบ RESTสำหรับรายละเอียดเพิ่มเติมเกี่ยวกับRESTและสัญลักษณ์แสดงหัวข้อย่อยที่ระบุข้างต้น

แก้ไข:อัปเดตเนื้อหาตามความคิดเห็น

SOAP ( Simple Object Access Protocol ) และ REST (การโอนย้ายสถานะแทน ) มีความสวยงามในแบบของพวกเขา ดังนั้นฉันไม่ได้เปรียบเทียบพวกเขา แต่ฉันกำลังพยายามพรรณนาภาพเมื่อฉันต้องการใช้ REST และ SOAP

น้ำหนักบรรทุกคืออะไร?

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

ตัวอย่างเช่นตอนนี้ฉันต้องส่งโทรเลขและเราทุกคนรู้ว่าค่าโทรเลขจะขึ้นอยู่กับบางคำ

บอกฉันทีด้านล่างทั้งสองข้อความซึ่งอันไหนถูกกว่าที่จะส่ง?

<name>Arin</name>

หรือ

"name": "Arin"

ฉันรู้ว่าคำตอบของคุณจะเป็นคำตอบที่สองแม้ว่าทั้งคู่จะแสดงถึงข้อความเดียวกันข้อที่สองนั้นราคาถูกกว่า

ดังนั้นฉันพยายามที่จะบอกว่าการส่งข้อมูลผ่านเครือข่ายในรูปแบบ JSON มีราคาถูกกว่าการส่งในรูปแบบ XML เกี่ยวกับน้ำหนักบรรทุก

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

ตอนนี้ SOAP รองรับ XML เท่านั้นแต่ก็มีข้อดีอยู่เช่นกัน

จริงๆ! อย่างไร?

SOAP อาศัย XML ในสามวิธีซองจดหมาย - ที่กำหนดสิ่งที่อยู่ในข้อความและวิธีการประมวลผล

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

ซองจดหมายนี้ส่งผ่านการส่งข้อมูล (HTTP / HTTPS) และดำเนินการ RPC (การเรียกกระบวนการระยะไกล) และซองจดหมายจะถูกส่งกลับพร้อมข้อมูลในเอกสารที่จัดรูปแบบ XML

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

ดังที่ฉันได้กล่าวไปแล้วในย่อหน้าข้างต้น“ REST ใช้ HTTP / HTTPS”ดังนั้นให้ลึกลงไปในคำเหล่านี้

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

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

นอกจากนั้นเนื่องจากREST ถูก จำกัด โดยโปรโตคอล HTTPดังนั้นการสนับสนุนการทำธุรกรรมจึงไม่สอดคล้องกับกรด

แต่ SOAP มีการสนับสนุนที่ครอบคลุมสำหรับทั้งการจัดการทรานแซคชั่นแบบอิงกรดสำหรับธุรกรรมระยะสั้นและการจัดการทรานแซคชันตามค่าตอบแทนสำหรับธุรกรรมระยะยาว นอกจากนี้ยังสนับสนุนสองเฟสกระทำข้ามการกระจายทรัพยากร

ฉันไม่ได้ข้อสรุปใด ๆ แต่ฉันจะชอบบริการบนเว็บของ SOAP ในขณะที่ความปลอดภัยธุรกรรม ฯลฯ เป็นประเด็นหลัก

นี่คือ "การ Java EE 6 กวดวิชา" ที่พวกเขาได้กล่าวว่าการออกแบบสงบอาจจะเหมาะสมเมื่อเงื่อนไขต่อไปนี้ ได้ดู

หวังว่าคุณจะสนุกกับการอ่านคำตอบของฉัน

REST ( RE presentational S tate T ransfer)
RE presentational S tate ของวัตถุคือT ransferred คือ REST เช่นเราไม่ส่ง Object เราจะส่งสถานะของวัตถุ REST เป็นสไตล์สถาปัตยกรรม ไม่ได้กำหนดมาตรฐานมากมายเช่น SOAP REST ใช้สำหรับเปิดเผย API สาธารณะ (เช่น Facebook API, Google Maps API) ผ่านทางอินเทอร์เน็ตเพื่อจัดการการทำงานของ CRUD กับข้อมูล ส่วนที่เหลือจะมุ่งเน้นไปที่การเข้าถึงทรัพยากรที่มีชื่อผ่านอินเตอร์เฟซที่สอดคล้องกันเดียว

สบู่ ( S Imple O bject ccess P rotocol) สบู่นำโปรโตคอลของตัวเองและมุ่งเน้นไปที่การเปิดเผยชิ้นส่วนของตรรกะของโปรแกรมประยุกต์ (ไม่ใช่ข้อมูล) การให้บริการ สบู่เปิดเผยการดำเนินงาน SOAP มุ่งเน้นไปที่การเข้าถึงการดำเนินงานที่มีชื่อแต่ละการดำเนินการใช้ตรรกะทางธุรกิจบางอย่าง แม้ว่า SOAP จะถูกเรียกโดยทั่วไปว่าเป็นเว็บเซอร์วิสซึ่งเป็นชื่อเรียกที่ไม่ถูกต้อง สบู่มีน้อยมากถ้ามีอะไรเกี่ยวข้องกับเว็บ REST ให้บริการเว็บที่แท้จริงโดยยึดตาม URIs และ HTTP

ทำไมต้องพัก

• เนื่องจาก REST ใช้ HTTP มาตรฐานมันจึงง่ายกว่ามากในแบบที่ไม่เคยมีมาก่อน
• REST นั้นง่ายต่อการติดตั้งใช้แบนด์วิดท์และทรัพยากรน้อยกว่า
• REST อนุญาตให้ใช้รูปแบบข้อมูลที่แตกต่างกันซึ่ง SOAP อนุญาตให้ใช้ XML เท่านั้น
• REST อนุญาตการสนับสนุนที่ดีขึ้นสำหรับเบราว์เซอร์ไคลเอ็นต์เนื่องจากการสนับสนุนสำหรับ JSON
• REST มีประสิทธิภาพและความสามารถในการขยายที่ดีขึ้น การอ่านส่วนที่เหลือสามารถแคชได้การอ่านที่ใช้ SOAP จะไม่สามารถแคชได้
• หากการรักษาความปลอดภัยไม่ใช่เรื่องที่สำคัญและเรามีทรัพยากรที่ จำกัด หรือเราต้องการสร้าง API ที่นักพัฒนาซอฟต์แวร์คนอื่นจะใช้อย่างเปิดเผยในที่สาธารณะแล้วเราควรไปกับ REST
• หากเราต้องการการดำเนินการ CRUD แบบไร้สัญชาติให้ไปกับ REST
• REST มักใช้ในโซเชียลมีเดียเว็บแชทบริการโทรศัพท์มือถือและ Public APIs เช่น Google Maps
• เซอร์วิส RESTful ส่งคืน MediaTypes ที่หลากหลายสำหรับทรัพยากรเดียวกันทั้งนี้ขึ้นอยู่กับพารามิเตอร์ส่วนหัวคำขอ "ยอมรับ" ในฐานะapplication/xmlหรือapplication/jsonสำหรับ POST และ/user/1234.jsonหรือ GET /user/1234.xmlสำหรับ GET
• เซอร์วิส REST นั้นถูกเรียกใช้โดยแอ็พพลิเคชันฝั่งไคลเอ็นต์ไม่ใช่ผู้ใช้ปลายทางโดยตรง
• ST in REST มาจากS tate T ransfer คุณถ่ายโอนสถานะไปรอบ ๆ แทนที่จะให้เซิร์ฟเวอร์เก็บไว้ทำให้การบริการ REST สามารถปรับขนาดได้

ทำไมต้องเป็นสบู่

• SOAP นั้นใช้งานง่ายและต้องการแบนด์วิธและทรัพยากรที่มากขึ้น
• คำร้องขอข้อความ SOAP ถูกประมวลผลช้ากว่าเมื่อเปรียบเทียบกับ REST และไม่ใช้กลไกการแคชเว็บ
• WS-Security:ในขณะที่ SOAP รองรับ SSL (เหมือนกับ REST) ​​แต่ยังรองรับ WS-Security ซึ่งเพิ่มคุณสมบัติความปลอดภัยระดับองค์กร
• WS-AtomicTransaction:ต้องการธุรกรรมกรดมากกว่าบริการคุณจะต้องใช้สบู่
• WS-ReliableMessaging:หากแอปพลิเคชันของคุณต้องการการประมวลผลแบบอะซิงโครนัสและระดับความน่าเชื่อถือและความปลอดภัยที่รับประกันได้ ส่วนที่เหลือไม่มีระบบส่งข้อความมาตรฐานและคาดว่าลูกค้าจะจัดการกับความล้มเหลวในการสื่อสารโดยลองใหม่
• หากความปลอดภัยเป็นเรื่องสำคัญและทรัพยากรไม่ จำกัด เราควรใช้บริการเว็บ SOAP เช่นถ้าเรากำลังสร้างบริการเว็บสำหรับเกตเวย์การชำระเงินงานที่เกี่ยวข้องกับการเงินและโทรคมนาคมเราควรไปกับ SOAP เพราะที่นี่จำเป็นต้องมีความปลอดภัยสูง

source1
source2

ข้อแตกต่างระหว่าง Rest และ Soap

สบู่

1. SOAP เป็นโปรโตคอล
2. SOAP ย่อมาจาก Simple Object Access Protocol
3. SOAP ไม่สามารถใช้ REST ได้เนื่องจากเป็นโปรโตคอล
4. SOAP ใช้อินเตอร์เฟสเซอร์วิสเพื่อเปิดเผยตรรกะทางธุรกิจ
5. SOAP กำหนดมาตรฐานที่จะต้องปฏิบัติตามอย่างเคร่งครัด
6. SOAP ต้องการแบนด์วิดท์และทรัพยากรมากกว่า REST
7. SOAP กำหนดความปลอดภัยของตัวเอง
8. SOAP อนุญาตให้ใช้รูปแบบข้อมูล XML เท่านั้น
9. SOAP เป็นที่ต้องการน้อยกว่า REST

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

1. REST เป็นสไตล์สถาปัตยกรรม
2. REST ย่อมาจาก Representational State Transfer
3. ส่วนที่เหลือสามารถใช้บริการเว็บ SOAP เพราะมันเป็นแนวคิดและสามารถใช้โปรโตคอลใด ๆ เช่น HTTP, SOAP
4. REST ใช้ URI เพื่อเปิดเผยตรรกะทางธุรกิจ
5. REST ไม่ได้กำหนดมาตรฐานมากเกินไปเช่น SOAP
6. REST ต้องการแบนด์วิดท์และทรัพยากรน้อยกว่า SOAP
7. บริการเว็บสงบเงียบได้รับมรดกมาตรการรักษาความปลอดภัยจากการขนส่งพื้นฐาน
8. ส่วนที่เหลืออนุญาตให้รูปแบบข้อมูลที่แตกต่างกันเช่นข้อความธรรมดา, HTML, XML, JSON ฯลฯ
9. REST เป็นที่ต้องการมากกว่า SOAP

สำหรับรายละเอียดเพิ่มเติมโปรดดูที่นี่

IMHO คุณไม่สามารถเปรียบเทียบ SOAP และ REST ที่มีสองสิ่งที่แตกต่างกัน

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

SOAPกำหนดรูปแบบข้อความตาม XML ที่แอปพลิเคชันที่เปิดใช้งานบริการบนเว็บใช้เพื่อสื่อสารซึ่งกันและกันผ่านอินเทอร์เน็ต ในการที่จะทำเช่นนั้นแอปพลิเคชันจำเป็นต้องมีความรู้ก่อนหน้าของสัญญาข้อความประเภทข้อมูล ฯลฯ

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

ครั้งแรกของทั้งหมด: อย่างเป็นทางการคำถามที่ถูกต้องจะเทียบweb services + WSDL + SOAPREST

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

อย่างไรก็ตามในทางปฏิบัติทุกคนก็เพิกเฉยเช่นนั้น

มีคำตอบทางเทคนิคอยู่แล้วดังนั้นฉันจะพยายามให้สัญชาตญาณ

สมมติว่าคุณต้องการเรียกใช้ฟังก์ชันในคอมพิวเตอร์ระยะไกลซึ่งมีการใช้งานในภาษาการเขียนโปรแกรมอื่น ๆ (ซึ่งมักเรียกว่าการเรียกขั้นตอนระยะไกล / RPC ) สมมติว่าฟังก์ชั่นสามารถพบได้ที่ URL ที่ระบุโดยบุคคลที่เขียนมัน คุณต้อง (อย่างใด) ส่งข้อความและได้รับการตอบสนอง ดังนั้นจึงมีคำถามสองข้อที่ต้องพิจารณา

• รูปแบบของข้อความที่คุณควรส่งคืออะไร
• ข้อความควรถูกนำไปมาอย่างไร

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

สำหรับคำถามที่สองมีคำตอบหลากหลาย แต่เพียงคนเดียวที่ใช้ในการปฏิบัติเป็นสบู่ แนวคิดหลักคือ: ห่อ XML ก่อนหน้า (ข้อความจริง) ลงในอีก XML หนึ่ง (มีข้อมูลการเข้ารหัสและสิ่งที่เป็นประโยชน์อื่น ๆ ) และส่งผ่าน HTTP เมธอด POST ของ HTTP ใช้เพื่อส่งข้อความเนื่องจากมีเนื้อความเสมอ

แนวคิดหลักของวิธีการทั้งหมดนี้คือการที่คุณmap URL ไปยังฟังก์ชั่นที่เป็นที่จะดำเนินการ ดังนั้นหากคุณมีรายชื่อลูกค้าในเซิร์ฟเวอร์บางแห่งและคุณต้องการดู / อัปเดต / ลบคุณต้องมี 3 URL:

• myapp/read-customer และในส่วนของข้อความให้ส่งรหัสของลูกค้าเพื่ออ่าน
• myapp/update-customer และในร่างกายส่งรหัสของลูกค้าเช่นเดียวกับข้อมูลใหม่
• myapp/delete-customer และรหัสในร่างกาย

วิธี REST จะเห็นสิ่งต่าง ๆ URL ไม่ควรแสดงถึงการกระทำ แต่เป็นสิ่ง (เรียกว่าทรัพยากรใน RING lingo) เนื่องจากโปรโตคอล HTTP (ซึ่งเราใช้อยู่แล้ว) รองรับคำกริยาให้ใช้คำกริยาเหล่านั้นเพื่อระบุว่าการกระทำใดที่จะดำเนินการกับสิ่งนั้น

ดังนั้นด้วยวิธีการส่วนที่เหลือจำนวน 12 ลูกค้าจะพบที่ myapp/customers/12URL ในการดูข้อมูลลูกค้าคุณกด URL พร้อมคำขอ GET ในการลบมันURL เดียวกันกับกริยา DELETE หากต้องการอัปเดตให้ใช้ URL เดิมที่มีกริยา POST และเนื้อหาใหม่ในเนื้อหาคำขอ

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

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

นอกจากนี้สำหรับ:

++ ข้อผิดพลาดที่เกิดขึ้นบ่อยครั้งเมื่อเข้าใกล้ REST คือคิดว่าเป็น“ บริการเว็บที่มี URL” - คิดว่า REST เป็นกลไกการเรียกขั้นตอนระยะไกล (RPC) อีกวิธีหนึ่งเช่น SOAP แต่ถูกเรียกผ่าน HTTP URL ธรรมดาและไม่มีความแข็งแรงของ SOAP XML เนมสเปซ

++ ในทางกลับกัน REST มีส่วนเกี่ยวข้องกับ RPC เพียงเล็กน้อย ในขณะที่ RPC ให้ความสำคัญกับการบริการและให้ความสำคัญกับการกระทำและคำกริยา REST เป็นทรัพยากรที่มุ่งเน้นสิ่งต่าง ๆ และคำนามที่ประกอบด้วยแอปพลิเคชัน

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

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