REST เป็นวิธีที่ดีกว่าในการทำ Web Services หรือ SOAP หรือไม่? หรือพวกเขาเป็นเครื่องมือต่าง ๆ สำหรับปัญหาต่าง ๆ ? หรือมันเป็นปัญหาที่เหมาะสมยิ่ง - นั่นคือเป็นสิ่งหนึ่งที่ดีกว่าเล็กน้อยในบางสถานการณ์อื่น ๆ หรือไม่?

ฉันจะขอขอบคุณข้อมูลเกี่ยวกับแนวคิดเหล่านั้นและความสัมพันธ์กับ PHP-universe และแอพพลิเคชั่นบนเว็บระดับสูงที่ทันสมัย

ฉันสร้างเซิร์ฟเวอร์ SOAP ตัวแรกซึ่งรวมถึงการสร้างรหัสและการสร้าง WSDL จากสเป็คดั้งเดิมตามที่มันถูกพัฒนาขึ้นเมื่อฉันทำงานที่ Hewlett-Packard ฉันไม่แนะนำให้ใช้สบู่เพื่ออะไร

คำย่อ "SOAP" เป็นเรื่องโกหก มันไม่ง่ายมันไม่ได้เป็นวัตถุเชิงมันกำหนดไม่มีกฎการเข้าถึง เป็นพิธีสาร มันเป็นสเป็คที่แย่ที่สุดของ Don Box และนั่นก็เป็นเรื่องที่ค่อนข้างประสบความสำเร็จ

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

XML-RPC กำหนดโปรโตคอลการตอบสนองและข้อผิดพลาดอย่างชัดเจนและมีไลบรารีที่ดีสำหรับภาษาส่วนใหญ่ อย่างไรก็ตาม XML นั้นหนักกว่าที่คุณต้องการสำหรับหลาย ๆ งาน

REST เป็นสถาปัตยกรรม SOAP เป็นโปรโตคอล

นั่นคือปัญหาแรก

คุณสามารถส่งซองจดหมาย SOAP ในแอปพลิเคชัน REST

SOAP นั้นค่อนข้างพื้นฐานและเรียบง่ายจริงๆแล้วมันเป็นมาตรฐานของ WSS- * ที่ทำให้ซับซ้อนมาก

หากผู้บริโภคของคุณเป็นแอพพลิเคชั่นอื่น ๆ และเซิร์ฟเวอร์อื่น ๆ ก็มีการรองรับโปรโตคอล SOAP มากมายในปัจจุบันและพื้นฐานของการย้ายข้อมูลคือการคลิกเมาส์ใน IDE ที่ทันสมัย

หากผู้บริโภคของคุณมีแนวโน้มที่จะเป็น RIA หรือลูกค้า Ajax คุณอาจต้องการสิ่งที่ง่ายกว่า SOAP และมีถิ่นกำเนิดของลูกค้ามากกว่า (โดยเฉพาะ JSON)

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

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

REST เป็นกระบวนทัศน์ที่แตกต่างจากสบู่ การอ่าน REST ที่ดีสามารถพบได้ที่นี่: ฉันจะอธิบายส่วนที่เหลือของภรรยาได้อย่างไร

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

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

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

คำถาม lowdown อย่างรวดเร็วสำหรับปี 2012:

พื้นที่ที่ REST ใช้งานได้ดีจริงๆคือ:

• แบนด์วิดท์และทรัพยากร จำกัด จำไว้ว่าโครงสร้างการส่งคืนนั้นอยู่ในรูปแบบใด ๆ (กำหนดโดยผู้พัฒนา) นอกจากนี้เบราว์เซอร์ใด ๆ สามารถใช้งานได้เนื่องจากวิธี REST ใช้คำกริยา GET, PUT, POST และ DELETE มาตรฐาน อีกครั้งโปรดจำไว้ว่า REST ยังสามารถใช้วัตถุ XMLHttpRequest ที่เบราว์เซอร์ที่ทันสมัยที่สุดรองรับในวันนี้ซึ่งเพิ่มโบนัสพิเศษของ AJAX

• การดำเนินการไร้สัญชาติโดยสิ้นเชิง  หากการดำเนินการต้องดำเนินการต่อ REST ไม่ใช่วิธีที่ดีที่สุดและ SOAP อาจเหมาะสมกว่า อย่างไรก็ตามหากคุณต้องการการดำเนินการ CRUD (สร้าง, อ่าน, อัปเดตและลบ) แบบไร้สัญชาติดังนั้น REST ก็คือ

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

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

• การประมวลผลแบบอะซิงโครนัสและการเรียกใช้  หากแอปพลิเคชันของคุณต้องการระดับความน่าเชื่อถือและความปลอดภัยที่รับประกัน SOAP 1.2 เสนอมาตรฐานเพิ่มเติมเพื่อให้แน่ใจว่าการทำงานประเภทนี้ สิ่งที่ต้องการ WSRM - การส่งข้อความ WS- เชื่อถือได้

• สัญญาอย่างเป็นทางการ  หากทั้งสองฝ่าย (ผู้ให้บริการและผู้บริโภค) ต้องยอมรับในรูปแบบการแลกเปลี่ยน SOAP 1.2 จะให้ข้อมูลจำเพาะที่เข้มงวดสำหรับการโต้ตอบประเภทนี้

• การดำเนินงาน stateful หากแอปพลิเคชันต้องการข้อมูลบริบทและการจัดการสถานะการสนทนา SOAP 1.2 มีข้อกำหนดเพิ่มเติมในโครงสร้าง WS * เพื่อสนับสนุนสิ่งเหล่านั้น (ความปลอดภัยธุรกรรมการประสานงาน ฯลฯ ) เปรียบเทียบ REST จะทำให้นักพัฒนาสร้างระบบประปาที่กำหนดเองนี้

http://www.infoq.com/articles/rest-soap-when-to-use-each

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

RESTนั้นง่ายขึ้นสามารถบำรุงรักษาได้ง่ายขึ้นซึ่งเป็นหัวใจสำคัญของสถาปัตยกรรมเว็บทำให้สามารถมองเห็นโปรโตคอลได้ดีขึ้นและได้รับการพิสูจน์แล้วว่าขยายขนาดของ WWW เฟรมเวิร์กบางส่วนนั้นช่วยให้คุณสร้างบริการ REST เช่น Ruby on Rails และบางเฟรมยังช่วยให้คุณเขียนไคลเอ็นต์เช่น ADO.NET Data Services แต่ส่วนใหญ่ขาดการสนับสนุนเครื่องมือ

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

ส่วนที่เหลือเล่นได้ดีกับ AJAX'y หน้าเว็บ หากคุณทำตามคำขอของคุณง่าย ๆ คุณสามารถโทรออกบริการได้โดยตรงจาก JavaScript และมีประโยชน์มาก พยายามหลีกเลี่ยงเนมสเปซใด ๆ ใน XML การตอบกลับของคุณฉันเห็นเบราว์เซอร์ทำให้หายใจไม่ออก ดังนั้น xsi: type อาจไม่เหมาะกับคุณไม่มี XML Schemas ที่ซับซ้อนเกินไป

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

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

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

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

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

1) การใช้เซอร์วิส REST จะใช้เวลานานกว่าการใช้เซอร์วิส SOAP อย่างไม่มีที่สิ้นสุด มีเครื่องมือสำหรับภาษา / กรอบงาน / แพลตฟอร์มที่ทันสมัยทั้งหมดเพื่ออ่านใน WSDL และคลาสพรอกซีเอาท์พุทและไคลเอนต์ การใช้บริการ REST นั้นทำด้วยมือและ - รับสิ่งนี้ - โดยการอ่านเอกสาร นอกจากนี้ในขณะที่ใช้งานบริการทั้งสองนี้คุณจะต้อง "คาดเดา" ว่าอะไรจะกลับมาที่ท่อเนื่องจากไม่มีสคีมาหรือเอกสารอ้างอิงจริง

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

3) ฉันเคยได้ยินคำร้องเรียนว่าด้วย SOAP คุณมี "ค่าใช้จ่าย" ของ SOAP Envelope ในวันนี้และอายุเราต้องกังวลเกี่ยวกับการหยิบไบต์?

4) ฉันได้ยินอาร์กิวเมนต์ว่าด้วย REST คุณสามารถป๊อปอัพ URL ในเบราว์เซอร์และดูข้อมูล แน่นอนว่าถ้าบริการ REST ของคุณใช้งานง่ายหรือไม่มีการตรวจสอบสิทธิ์ ตัวอย่างเช่นบริการ Netflix ใช้ OAuth ซึ่งต้องการให้คุณลงชื่อสิ่งต่างๆและเข้ารหัสสิ่งต่างๆก่อนที่คุณจะสามารถส่งคำขอของคุณได้

5) ทำไมเราต้องมี URL ที่ "อ่านได้" สำหรับแต่ละทรัพยากร? หากเราใช้เครื่องมือเพื่อใช้บริการเราสนใจ URL จริงหรือไม่?

ฉันต้องการดำเนินการต่อหรือไม่

แอปพลิเคชันส่วนใหญ่ที่ฉันเขียนคือฝั่งเซิร์ฟเวอร์ C # หรือ Java หรือแอปพลิเคชันเดสก์ท็อปใน WinForms หรือ WPF แอปพลิเคชันเหล่านี้มักจะต้องใช้ API บริการที่สมบูรณ์ยิ่งขึ้นกว่าที่ REST สามารถให้ได้ นอกจากนี้ฉันไม่ต้องการใช้เวลามากกว่าสองสามนาทีในการสร้างไคลเอนต์บริการเว็บของฉัน เครื่องมือสร้างไคลเอ็นต์การประมวลผล WSDL อนุญาตให้ฉันนำไคลเอ็นต์ของฉันไปใช้และเพิ่มมูลค่าทางธุรกิจ

ตอนนี้ถ้าฉันกำลังเขียนบริการเว็บอย่างชัดเจนสำหรับการโทร ajax javascript บางอันมันอาจจะอยู่ใน REST เพียงเพื่อรู้เทคโนโลยีของลูกค้าและใช้ประโยชน์จาก JSON ในความคิดของฉัน API บริการเว็บที่ใช้จาก javascript อาจไม่ซับซ้อนมากเนื่องจากความซับซ้อนประเภทนั้นดูเหมือนว่าจะจัดการกับฝั่งเซิร์ฟเวอร์ได้ดีขึ้น

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

ฉันขอแนะนำให้คุณใช้ REST ก่อนถ้าคุณใช้ Java ดูที่ JAX-RS และการติดตั้งJersey ส่วนที่เหลือนั้นง่ายกว่าและง่ายต่อการทำงานร่วมกันในหลายภาษา

ดังที่คนอื่น ๆ ได้กล่าวไว้ในหัวข้อนี้ปัญหาเกี่ยวกับ SOAP นั้นมีความซับซ้อนเมื่อข้อกำหนดของ WS- * อื่นเข้ามาและมีปัญหาการทำงานร่วมกันนับไม่ถ้วนหากคุณหลงทางในส่วนที่ไม่ถูกต้องของ WSDL, XSDs, SOAP, WS-Addressing เป็นต้น

วิธีที่ดีที่สุดในการตัดสินการอภิปราย REST v SOAP คือดูบนอินเทอร์เน็ต - ผู้เล่นรายใหญ่ทุกคนในพื้นที่เว็บ, google, amazon, ebay, twitter และคณะ - มักจะใช้และชอบ API RESTful มากกว่า SOAP

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

ฉันแน่ใจว่ากล่องดอนสร้างสบู่เป็นเรื่องตลก - 'ดูสิคุณทำได้โทรหาวิธี RPC ผ่านเว็บ' และในวันนี้คร่ำครวญเมื่อเขาตระหนักว่าฝันร้ายที่ป่องของมาตรฐานเว็บมันกลายเป็น :-)

ส่วนที่เหลือเป็นสิ่งที่ดีเรียบง่ายใช้งานได้ทุกที่ (มากกว่า "มาตรฐาน" มากกว่ามาตรฐาน) อย่างรวดเร็วและง่ายดาย ใช้ REST

ฉันคิดว่าทั้งคู่มีที่ของตัวเอง ในความเห็นของฉัน:

สบู่ : ทางเลือกที่ดีกว่าสำหรับการรวมระหว่างระบบดั้งเดิม / ระบบที่สำคัญและระบบเว็บ / บริการบนเว็บในระดับพื้นฐานที่ WS- * เหมาะสม (ความปลอดภัยนโยบาย ฯลฯ )

RESTful : ตัวเลือกที่ดีกว่าสำหรับการรวมระหว่างเว็บไซต์กับ public API ที่ด้านบนสุดของเลเยอร์ (ดูเช่น javascripts ที่รับสายไปยัง URIs)

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

(otoh คุณสามารถใช้คุกกี้กับบริการ REST เพื่อส่ง "header" - พิมพ์ข้อมูลนอกแบนด์ได้หรือไม่?)

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

ตอบคำถามการรีเฟรช 2012 (ตามค่าหัวครั้งที่สอง) และตรวจสอบผลลัพธ์ของวันนี้ (คำตอบอื่น ๆ )

สบู่ข้อดีข้อเสีย

เกี่ยวกับ SOAP 1.2 ข้อดีและข้อเสียเมื่อเปรียบเทียบกับ "REST" ... ดีตั้งแต่ปี 2550 คุณสามารถอธิบาย REST บริการเว็บด้วย WSDLและใช้โปรโตคอล SOAP ... นั่นคือถ้าคุณทำงานหนักขึ้นเล็กน้อยมาตรฐาน W3C ทั้งหมดของ โปรโตคอลเว็บเซอร์วิสโปรโตคอลสามารถเป็น REST !

มันเป็นจุดเริ่มต้นที่ดีเพราะเราสามารถจินตนาการสถานการณ์ที่หลีกเลี่ยงการอภิปรายทางปรัชญาและระเบียบวิธีทั้งหมด เราสามารถเปรียบเทียบทางเทคนิค "SOAP-REST" กับ "NON-SOAP-REST" ในบริการที่คล้ายกัน

• SOAP-REST (= "REST-SOAP"): ตามที่แสดงโดย L.Mandel , WSDL2 สามารถอธิบาย webservice REST และถ้าเราสมมติว่า XML แบบสุดขั้วสามารถห่อหุ้มใน SOAP การใช้งานทั้งหมดจะเป็น "SOAP-REST" .

• NON-SOAP-REST : บริการเว็บ REST ใด ๆ ที่ไม่สามารถเป็นสบู่ ... นั่นคือ "90%" ของตัวอย่าง REST ที่มีความรู้ดี บางคนไม่ใช้ XML (เช่นปกติ AJAX REST ใช้ JSON แทน) บางคนใช้โครงสร้าง XML อื่นโดยไม่มีส่วนหัว SOAP หรือกฎ PS: เพื่อหลีกเลี่ยงความไม่เป็นทางการเราสามารถสมมติREST ระดับ 2ในการเปรียบเทียบ

แน่นอนเพื่อเปรียบเทียบแนวคิดเพิ่มเติมเปรียบเทียบ "NON-REST-SOAP" กับ "NON-SOAP-REST" เป็นวิธีการสร้างแบบจำลองที่แตกต่างกัน ดังนั้นการทำ taxonomy ของเว็บเซอร์วิสนี้ให้สมบูรณ์:

• NON-REST-SOAP : บริการเว็บ SOAP ใด ๆ ที่ไม่สามารถ REST ... นั่นคือ "90%" ของตัวอย่าง SOAP ที่มีความรอบรู้

• NON-REST-NEITHER-SOAP : ใช่จักรวาลของ "การสร้างแบบจำลองการบริการเว็บ" ประกอบด้วยสิ่งอื่น ๆ (เช่นXML-RPC )

สบู่ในการลงโทษส่วนที่เหลือ

เปรียบเทียบสิ่งที่เทียบเคียง: SOAP ส่วนที่เหลือกับNON-SOAP ส่วนที่เหลือ

ข้อดี

อธิบายบางคำ

• ความมั่นคงตามสัญญา : สำหรับสัญญาทุกประเภท (เป็น "ข้อตกลงที่เป็นลายลักษณ์อักษร"),

  • โดยการใช้ standars : ทุกระดับของสแต็ก W3C สอดคล้องกัน REST นั้นไม่ใช่มาตรฐาน W3C หรือ ISO และไม่มีรายละเอียดเกี่ยวกับอุปกรณ์ต่อพ่วงของบริการ ดังนั้นในขณะที่ฉัน @DaveWoldrich (20 โหวต), @cynicalman (5), @ Exos (0) พูดก่อนหน้านี้ในบริบทที่จำเป็นต้องมีมาตรฐานคุณต้องใช้สบู่

  • โดยการใช้แนวทางปฏิบัติที่ดีที่สุด : "แง่มุมอย่างละเอียด" ของการใช้งานสแต็ก W3Cแปลข้อตกลงระหว่างมนุษย์ / กฎหมาย / กฎหมายที่เกี่ยวข้อง

• ความทนทาน : ความปลอดภัยของโครงสร้าง SOAP และส่วนหัว ด้วยการสื่อสารแบบเมตาดา (ด้วยการแสดงออกอย่างเต็มที่ของ XML) และการตรวจสอบคุณมี "นโยบายการประกัน" กับการเปลี่ยนแปลงหรือเสียงรบกวน
  สบู่มี "ความน่าเชื่อถือในการทำธุรกรรม ( ... ) การจัดการกับความล้มเหลวของการสื่อสาร. SOAP มีการควบคุมมากขึ้นรอบตรรกะลองใหม่อีกครั้งและทำให้สามารถให้มากขึ้นแบบ end-to-end ความน่าเชื่อถือและการบริการการค้ำประกัน" อี Terman

จัดเรียงข้อดีตามความนิยม

• เครื่องมือที่ดีขึ้น (~ 70 โหวต): ปัจจุบัน SOAP มีข้อได้เปรียบของเครื่องมือที่ดีกว่าตั้งแต่ปี 2550 และปี 2555 เพราะเป็นมาตรฐานที่ได้รับการยอมรับอย่างกว้างขวาง ดู @ MarkCidade (27 votes), @DaveWoldrich (20), @JoshM (13), @ TravisHeseman (9)

• การปฏิบัติตามมาตรฐาน (25 โหวต): ในขณะที่ฉัน @DaveWoldrich (20 คะแนนโหวต), @cynicalman (5), @ Exitos (0) กล่าวก่อนหน้านี้ในบริบทที่จำเป็นต้องใช้มาตรฐาน

• Robustness : การประกัน SOAP header, @JohnSaunders (8 votes)

ข้อเสีย

• โครงสร้างของสบู่มีความซับซ้อนมากขึ้น (มากกว่า 300 คะแนน): คำตอบทั้งหมดที่นี่และแหล่งที่มาเกี่ยวกับ "สบู่กับส่วนที่เหลือ" แสดงให้เห็นถึงระดับที่ไม่ชอบด้วยความซ้ำซ้อนและความซับซ้อนของสบู่ นี่เป็นผลตามธรรมชาติของข้อกำหนดสำหรับการยืนยันอย่างเป็นทางการ (ดูด้านล่าง) และเพื่อความทนทาน (ดูด้านบน) "REST NON-SOAP" (และ XML-RPC ผู้สร้าง SOAP ) สามารถทำได้ง่ายและไม่เป็นทางการ

• "การเพียง XML" ข้อ จำกัด เป็นอุปสรรคประสิทธิภาพเมื่อใช้บริการเล็ก ๆ (~ 50 โหวต): ดูjson.org/xmlและคำถามนี้หรือนี้คนอื่น ๆ จุดนี้แสดงโดย @toluju (41) และอื่น ๆ
  PS: เนื่องจากJSON ไม่ใช่มาตรฐาน IETFแต่เราสามารถพิจารณามาตรฐานจริงสำหรับชุมชนซอฟต์แวร์เว็บ

บริการสร้างแบบจำลองด้วย SOAP

ตอนนี้เราสามารถเพิ่มSOAP-NON-RESTด้วยการเปรียบเทียบNON-SOAP-RESTและอธิบายว่าเมื่อใดควรใช้ SOAP :

• ต้องการสำหรับมาตรฐานและสัญญาที่มั่นคง (ดูที่ส่วน "ข้อดี") PS: เห็นทั่วไป "ต้อง B2B สำหรับมาตรฐาน" อธิบายโดย @saille

• ต้องการเครื่องมือ (ดูที่ส่วน "ข้อดี") PS: มาตรฐานและการมีอยู่ของการตรวจสอบอย่างเป็นทางการ (ดูซอลเบลโลว์) เป็นประเด็นสำคัญสำหรับเครื่องมืออัตโนมัติ

• การประมวลผลแบบขนานจำนวนมาก (ดูที่ "บริบท / รากฐาน" ด้านล่าง): ด้วยกระบวนการที่ใหญ่กว่าและ / หรือช้ากว่าไม่ว่าจะมี SOAP ที่ซับซ้อนเพิ่มขึ้นอีกเล็กน้อยความน่าเชื่อถือและความเสถียรคือการลงทุนที่ดีที่สุด

• ต้องการความปลอดภัยมากขึ้น : เมื่อต้องการมากกว่า HTTPS และคุณต้องการคุณสมบัติเพิ่มเติมเพื่อการป้องกัน SOAP เป็นตัวเลือกที่ดีกว่า ( ดู @Bell , โหวต 32 คะแนน) "การส่งข้อความไปตามเส้นทางที่มีความซับซ้อนมากขึ้นกว่าการร้องขอ / การตอบสนองหรือการขนส่งที่ไม่เกี่ยวข้องกับ HTTP เป็น", S. Seely XML เป็นปัญหาหลักที่นำเสนอมาตรฐานXML Encryption , XML ลายเซ็นและXML Canonicalizationและเฉพาะกับสบู่คุณสามารถที่จะฝังกลไกเหล่านี้ลงในข้อความโดยมาตรฐานที่ดีได้รับการยอมรับเป็นWS-Security

• ต้องการความยืดหยุ่นมากขึ้น (ข้อ จำกัด น้อยลง): SOAP ไม่ต้องการการโต้ตอบที่แน่นอนกับ URI ไม่ จำกัด ไม่ให้ HTTP; ไม่จำเป็นต้อง จำกัด เพียง 4 คำกริยา ตามที่ @ TravisHeseman (9 คะแนนโหวต) กล่าวว่าหากคุณต้องการบางสิ่งบางอย่าง "ยืดหยุ่นสำหรับจำนวนลูกค้าเทคโนโลยีและการใช้งาน" ให้ใช้ SOAP
  PS: โปรดจำไว้ว่า XML นั้นเป็นสากล / มีความหมายมากกว่า JSON (et al)

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

บริบท

ประวัติศาสตร์

เพื่อประเมินแนวโน้มเป็นมุมมองทางประวัติศาสตร์ที่จำเป็น สำหรับหัวข้อนี้มุมมอง 10 หรือ 15 ปี ...

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

สำหรับงานประจำวันเช่นการใช้ AJAX, SOAP นั้นหนัก ... ดังนั้นความจำเป็นในการใช้วิธีง่าย ๆ จึงจำเป็นต้องเลือกกรอบทฤษฎีใหม่ ... และ "ผู้เล่นซอฟต์แวร์เว็บขนาดใหญ่" อย่าง Google, Amazon Yahoo, et al, เลือกทางเลือกที่ดีที่สุดนั่นคือวิธี REST เป็นในบริบทนี้ที่แนวคิด REST มาถึงเป็น "กรอบการแข่งขัน" และวันนี้ (2012), ทางเลือกนี้เป็นมาตรฐานโดยพฤตินัยสำหรับโปรแกรมเมอร์

ฐานราก

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

เมื่องานมีขนาดใหญ่ขึ้นก็จะกลายเป็น "การอภิปรายความซับซ้อน" ที่สำคัญน้อยลงและมีความเกี่ยวข้องกับความแข็งแกร่งของการสื่อสารและความแข็งแกร่งของสัญญา

มันเหมาะสมยิ่ง

หากคุณจำเป็นต้องมีระบบอื่น ๆ เชื่อมต่อกับบริการของคุณลูกค้าจำนวนมากจะพอใจกับ SOAP มากขึ้นเนื่องจากเลเยอร์ของ "การยืนยัน" ที่คุณมีกับสัญญา WSDL และมาตรฐาน SOAP

สำหรับการโทรเข้าสู่ระบบแบบวันต่อวันฉันคิดว่า SOAP เป็นค่าใช้จ่ายที่ไม่จำเป็นจำนวนมากเมื่อมีการโทร HTML ง่ายๆ

ฉันกำลังมองหาที่เดียวกันและฉันคิดว่า พวกเขาเป็นเครื่องมือที่แตกต่างกันสำหรับปัญหาที่แตกต่างกันพวกเขาเป็นเครื่องมือที่แตกต่างกันสำหรับปัญหาที่แตกต่างกัน

มาตรฐาน Simple Object Access Protocol (SOAP) ภาษา XML ที่กำหนดสถาปัตยกรรมข้อความและรูปแบบข้อความถูกใช้โดยเว็บเซอร์วิสซึ่งมีคำอธิบายของการดำเนินการ WSDL เป็นภาษาที่ใช้ XML สำหรับอธิบายบริการเว็บและวิธีการเข้าถึง จะทำงานบน SMTP, HTTP, FTP เป็นต้นต้องใช้การสนับสนุนมิดเดิลแวร์, กลไกที่กำหนดไว้อย่างดีเพื่อกำหนดบริการเช่น WSDL + XSD, นโยบาย WS สบู่จะส่งคืนข้อมูล XML ตาม SOAP ให้มาตรฐานความปลอดภัยและความน่าเชื่อถือ

บริการบนเว็บ Representational State Transfer (RESTful) เป็นบริการบนเว็บรุ่นที่สอง บริการเว็บสงบสื่อสารผ่าน HTTP กว่าบริการบน SOAP และไม่ต้องการข้อความ XML หรือข้อกำหนด WSDL service-API สำหรับ REST ไม่จำเป็นต้องใช้มิดเดิลแวร์เพียงสนับสนุน HTTP เท่านั้นมาตรฐาน WADL, REST สามารถส่งคืน XML, ข้อความธรรมดา, JSON, HTML เป็นต้น

เป็นการง่ายขึ้นสำหรับลูกค้าหลายประเภทที่จะใช้บริการเว็บ RESTful ในขณะที่เปิดใช้งานฝั่งเซิร์ฟเวอร์ในการพัฒนาและปรับขนาด ลูกค้าสามารถเลือกที่จะใช้บริการบางส่วนหรือทั้งหมดและรวมเข้ากับบริการบนเว็บอื่น ๆ

1. REST ใช้ HTTP มาตรฐานเพื่อสร้างไคลเอนต์ได้ง่ายขึ้นและกำลังพัฒนา API
2. REST อนุญาตให้ใช้รูปแบบข้อมูลที่แตกต่างกันมากมายเช่น XML, ข้อความธรรมดา, JSON, HTML โดยที่ SOAP อนุญาตให้ใช้ XML เท่านั้น
3. REST มีประสิทธิภาพและความสามารถในการขยายที่ดีขึ้น
4. พักผ่อนและสามารถแคชได้และ SOAP ไม่สามารถทำได้
5. การจัดการข้อผิดพลาดในตัวที่ SOAP ไม่มีการจัดการข้อผิดพลาด
6. ส่วนที่เหลือมีประโยชน์อย่างยิ่ง PDA และอุปกรณ์มือถืออื่น ๆ

ส่วนที่เหลือคือบริการที่ง่ายต่อการรวมเข้ากับเว็บไซต์ที่มีอยู่

SOAP มีชุดโปรโตคอลซึ่งให้มาตรฐานด้านความปลอดภัยและความน่าเชื่อถือเหนือสิ่งอื่นใดและทำงานร่วมกับ WS ที่สอดคล้องกับไคลเอนต์และเซิร์ฟเวอร์ บริการเว็บ SOAP (เช่น JAX-WS) มีประโยชน์ในการจัดการการประมวลผลแบบอะซิงโครนัสและการเรียกใช้

สำหรับ SOAP ของ API แบบซับซ้อนจะมีประโยชน์มากกว่า

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

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

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

ฉันกำลังดูปัญหาเดียวกัน ดูเหมือนว่าสำหรับฉันแล้วที่จริงแล้ว REST นั้นรวดเร็วและง่ายและดีสำหรับการโทรและการตอบกลับที่มีน้ำหนักเบาและดีสำหรับการดีบั๊ก

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

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

จากมุมมองทางธุรกิจสิ่งนี้ทำให้การสื่อสารเปิดสู่การตีความและการเปลี่ยนแปลงซึ่งดูเหมือนจะเป็นความคิดที่ไม่ดี

'คำตอบ' ด้านบนในเธรดนี้ดูเหมือนว่า SOAP หมายถึง Simple Object-oriented Access Protocol อย่างไรก็ตามการดูวิกิ O หมายถึง Object ไม่ใช่ Object-oriented พวกมันต่างกัน

ฉันรู้ว่าโพสต์นี้เก่ามาก แต่คิดว่าฉันควรตอบสนองต่อสิ่งที่ฉันค้นพบเอง

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

ฉันอยากรู้ว่าคนอื่นคิดอย่างไร

ฟังพอดคาสต์นี้เพื่อค้นหา หากคุณต้องการทราบคำตอบโดยไม่ฟังคำตอบก็คือ REST แต่ฉันแนะนำให้ฟังจริงๆ

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

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

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

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

SOAPรวบรวมวิธีการที่มุ่งเน้นบริการไปยังบริการบนเว็บ - วิธีหนึ่งที่วิธีการ (หรือคำกริยา) เป็นวิธีหลักที่คุณโต้ตอบกับบริการ ส่วนที่เหลือจะใช้วิธีการที่มุ่งเน้นทรัพยากรที่วัตถุ (หรือคำนาม) ใช้เวทีกลาง

ในความหมายกับการสนับสนุน PHP "PHP-universe" สำหรับ SOAP ขั้นสูงใด ๆ ก็ดูดครั้งใหญ่ คุณจะต้องใช้อะไรเช่นhttp://wso2.com/products/web-services-framework/php/ทันทีที่คุณข้ามความต้องการขั้นพื้นฐานแม้กระทั่งเปิดใช้งาน WS-Security หรือ WS-RM ที่ไม่มีการสนับสนุนในตัว

การสร้างซองจดหมายสบู่ฉันรู้สึกยุ่งมากใน PHP, วิธีสร้างเนมสเปซ, xsd: ไม่มี, xsd: anytype และสบู่สไตล์เก่าที่ใช้บริการการเข้ารหัส SOAP (พระเจ้าทรงรู้ว่ามันแตกต่างกันอย่างไร) ในข้อความสบู่

หลีกเลี่ยงความยุ่งเหยิงทั้งหมดนี้ด้วยการเกาะติดกับ REST REST ไม่มีอะไรใหญ่เลยที่เราใช้ตั้งแต่เริ่ม WWW เรารับรู้เฉพาะเมื่อกระดาษhttp://www.ics.uci.edu/~fielding/pubs/dissertation/top.htmนี้ออกมาแสดงให้เห็นว่าเราสามารถใช้ความสามารถ HTTP ในการใช้งาน RESTFul Services ได้อย่างไร HTTP คือ REST โดยเนื้อแท้ซึ่งไม่ได้หมายความว่าเพียงแค่ใช้ HTTP เท่านั้นทำให้บริการของคุณ RESTFul

SOAP ละเลยความสามารถหลักของ HTTP และพิจารณาว่า HTTP เป็นโปรโตคอลการขนส่งดังนั้นจึงเป็นโปรโตคอลการขนส่งที่เป็นอิสระในทางทฤษฎี (ในทางปฏิบัติไม่ใช่กรณีที่คุณเคยได้ยินส่วนหัว SOAP Action หรือไม่ถ้าไม่ใช่ google ตอนนี้!)

ด้วยการเพิ่มการปรับตัว JSON และ HTML5 กับจาวาสคริปต์สุก REST กับ JSON ได้กลายเป็นวิธีที่พบบ่อยที่สุดในการจัดการกับบริการ JSON Schema ยังถูกกำหนดไว้สามารถใช้สำหรับโซลูชันระดับองค์กร (ยังอยู่ในช่วงเริ่มต้น) พร้อมกับ WADL หากจำเป็น

การสนับสนุน PHP สำหรับ REST และ JSON นั้นดีกว่าการสนับสนุน SOAP inbuilt ที่มีอยู่เดิม

เพิ่มคำ BUZZ เพิ่มเติมอีกไม่กี่ที่นี่ SOA, WOA, ROA

http://blog.dhananjaynene.com/2009/06/rest-soa-woa-or-roa/

http://www.scribd.com/doc/15657444/REST-White-Paper

โดยวิธีที่ฉันรัก SOAP โดยเฉพาะอย่างยิ่งสำหรับสเปค WS-Security นี่เป็นสเป็คที่ดีและถ้าใครบางคนที่คิดในการปรับตัวขององค์กร JSON จำเป็นต้องมาพร้อมกับสิ่งที่คล้ายกันสำหรับ JSON เช่นการเข้ารหัสระดับฟิลด์เป็นต้น

หนึ่งจุดด่วน - โปรโตคอลการส่งและการประสาน;

ฉันใช้ SOAP ผ่าน TCP เพื่อความเร็วความน่าเชื่อถือและเหตุผลด้านความปลอดภัยรวมถึงเครื่องที่ติดตั้งไว้กับ machine services (ESB) และบริการภายนอก เปลี่ยนนิยามเซอร์วิส, orchestration ทำให้เกิดข้อผิดพลาดจากการเปลี่ยนแปลง WSDL และชัดเจนทันทีและสามารถสร้าง / ปรับใช้ใหม่ได้

ไม่แน่ใจว่าคุณสามารถทำเช่นเดียวกันกับ REST - ฉันรอการแก้ไขหรือแน่นอน! ด้วย REST เปลี่ยนนิยามบริการ - ไม่มีอะไรรู้จนกว่าจะคืนค่า 400 (หรืออะไรก็ตาม)

หากคุณกำลังมองหาการทำงานร่วมกันระหว่างระบบและภาษาที่แตกต่างกันฉันจะไปหา REST แน่นอน ฉันมีปัญหามากมายที่พยายามทำให้ SOAP ทำงานระหว่าง. NET และ Java เช่น

ฉันสร้างมาตรฐานเพื่อค้นหาสิ่งที่เร็วกว่านี้! ฉันเห็นผลลัพธ์นี้:

สำหรับ 1,000 คำขอ:

• REST ใช้เวลา 3 วินาที
• สบู่ใช้เวลา 7 วินาที

สำหรับ 10,000 คำขอ:

• REST ใช้เวลา 33 วินาที
• สบู่ใช้เวลา 69 วินาที

สำหรับ 1,000,000 คำขอ:

• ส่วนที่เหลือใช้เวลา 62 วินาที
• SOAP ใช้เวลา 114 วินาที

คำถามเก่า แต่ยังมีความเกี่ยวข้องในวันนี้ .... เนื่องจากผู้พัฒนาจำนวนมากในพื้นที่องค์กรยังคงใช้งานอยู่

งานของฉันเกี่ยวข้องกับการออกแบบและพัฒนาโซลูชัน IoT (Internet of Things) ซึ่งรวมถึงการพัฒนารหัสสำหรับอุปกรณ์ฝังตัวขนาดเล็กที่สื่อสารกับ Cloud

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

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

1. จากประสบการณ์ของฉัน ฉันจะบอกว่าส่วนที่เหลือให้คุณเลือกในการเข้าถึง URL ที่สร้างขึ้นแล้ว เช่น -> การค้นหาคำใน google URL นั้นสามารถใช้เป็น webservice สำหรับ REST ใน SOAP คุณสามารถสร้างบริการเว็บของคุณเองและเข้าถึงผ่าน SOAP ไคลเอนต์

2. REST รองรับข้อความ, JSON, รูปแบบ XML ดังนั้นความหลากหลายมากขึ้นสำหรับการสื่อสารระหว่างสองแอปพลิเคชัน ในขณะที่ SOAP รองรับเฉพาะรูปแบบ XML สำหรับการสื่อสารข้อความ