บริการเว็บสไตล์ Netflix หรือ Twitter ควรใช้ REST หรือ SOAP หรือไม่? [ปิด]

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

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 จริงหรือไม่?

นกขมิ้นในเหมืองถ่านหิน

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

สัญญาณเตือนภัย

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

บริการที่ส่งคืนแอปพลิเคชัน / xml และ application / json นั้นน่ารำคาญสำหรับผู้พัฒนาไคลเอ็นต์ เราควรทำอย่างไรกับหยดข้อมูลนั้น

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

สบู่โสหุ้ย มันแฝงที่ฆ่า หากผู้คนกังวลเกี่ยวกับจำนวนไบต์ที่มากเกินไปที่จะผ่านสายดังนั้น HTTP อาจไม่ใช่ตัวเลือกที่ถูกต้อง คุณเคยเห็นว่ามีผู้ใช้ส่วนหัว - เอเจนต์จำนวนไบต์กี่ไบต์?

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

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

ภัยพิบัติที่ใกล้เข้ามา

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

อย่างไรก็ตามพวกเขาพบว่าการกำหนดเวอร์ชันเป็นปัญหามาก แต่คอมไพเลอร์ไม่ได้ช่วยตรวจจับปัญหา รหัสลูกค้าที่เขียนด้วยมือถือเป็นความเจ็บปวดในการรักษาเนื่องจากโครงสร้างข้อมูลมีวิวัฒนาการและ URL จะได้รับการปรับโครงสร้างใหม่ การออกแบบ APIs โดยใช้คำนามและคำกริยาสี่คำนั้นยากมากโดยเฉพาะอย่างยิ่ง Zealots RESTful Url ที่จะบอกคุณว่าคุณสามารถและไม่สามารถใช้สตริงการสืบค้นได้

นักพัฒนากำลังจะเริ่มถามว่าทำไมเราถึงพยายามสนับสนุนทั้งรูปแบบ Json และรูปแบบ Xml ทำไมไม่เพียง แต่มุ่งเน้นความพยายามของเราไปที่หนึ่งและทำมันได้ดี?

สิ่งต่าง ๆ เกิดขึ้นได้อย่างไร

ฉันจะบอกคุณว่ามีอะไรผิดปกติ เราในฐานะนักพัฒนาให้ฝ่ายการตลาดใช้ประโยชน์จากจุดอ่อนหลักของเรา การค้นหานิรันดร์ของเราสำหรับกระสุนเงินทำให้เราตาบอดต่อความเป็นจริงของ REST ที่แท้จริง บนพื้นผิวส่วนที่เหลือดูเหมือนง่ายและเรียบง่าย ตั้งชื่อทรัพยากรของคุณด้วย Urls และใช้ GET, PUT, POST และ DELETE นรกเรา devs รู้อยู่แล้วว่าจะทำอย่างไรเราได้รับการจัดการกับฐานข้อมูลสำหรับปีที่มีตารางและคอลัมน์และคำสั่ง SQL ที่มี SELECT, INSERT, UPDATE และ DELETE มันควรจะเป็นเค้กชิ้นหนึ่ง

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

REST เวอร์ชันที่ถูกลดทอนลงนี้ได้รับการตรวจสอบในวัฒนธรรมนักพัฒนาซอฟต์แวร์ในหลาย ๆ ด้าน เฟรมเวิร์กเซิร์ฟเวอร์ถูกสร้างขึ้นที่สนับสนุนการระบุทรัพยากรและส่วนต่อประสานที่เหมือนกัน แต่ไม่ได้ทำอะไรเลยเพื่อสนับสนุนข้อ จำกัด อื่น ๆ ข้อตกลงเริ่มลอยไปรอบ ๆ สร้างความแตกต่างของวิธีการ (HI-REST กับ LO-REST, Corporate REST เทียบกับ REST เชิงวิชาการ, REST และ RESTful)

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

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

คุณเข้าใจผิดฉันกลัว

หากคุณทำไปได้มากคำตอบสั้น ๆ สำหรับคำถามของคุณก็คือ APIs เหล่านั้น (Netflix และ Twitter) ไม่สอดคล้องกับข้อ จำกัด ทั้งหมดดังนั้นคุณจะไม่ได้รับผลประโยชน์ที่ apis REST ควรนำมาใช้

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

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

คุณต้อง "เดา" ว่าอะไรจะกลับมาที่ท่อเนื่องจากไม่มีสคีมาหรือเอกสารอ้างอิงจริง

คุณถูกต้องอย่างแน่นอนสำหรับบริการเช่น Twitter อย่างไรก็ตามข้อ จำกัด ที่อธิบายตัวเองใน REST บอกว่าส่วนหัวของชนิดเนื้อหา HTTP ควรอธิบายเนื้อหาที่ถูกส่งผ่านสาย การนำเสนอแอปพลิเคชัน / json และ application / xml ไม่ได้บอกอะไรเกี่ยวกับเนื้อหา

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

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

จุดสุดท้ายของคุณเกี่ยวกับ URL ที่อ่านได้คือสิ่งที่น่าขันที่สุด หากคุณยอมรับข้อ จำกัด ของไฮเปอร์มีเดียอย่างแท้จริงทุก URL อาจเป็น GUID และนักพัฒนาไคลเอ็นต์จะไม่เสียสิ่งใดในการอ่าน

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

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

อาจไม่ใช่ความผิดทั้งหมดของพวกเขา

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

หากรหัสฮาร์ไคลเอนต์ urls เพื่อเข้าถึงทรัพยากรบางประเภทก็จะป้องกันเซิร์ฟเวอร์จากการเปลี่ยน URL เหล่านั้น การสร้าง URL ประเภทใดก็ตามโดยอาศัยความรู้โดยนัยว่าโครงสร้างบริการ URL นั้นเป็นการละเมิดอย่างไร

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

พวกเขาควรใช้ SOAP หรือไม่?

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

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

REST เป็นวิธีการวางแนวเอกสารที่ใช้คุณสมบัติของโปรโตคอลที่มีอยู่ (HTTP) "REST" เป็นเพียงคำศัพท์ - แนวคิดคือ: ใช้เว็บในแบบที่ออกแบบไว้ให้ทำงาน!

ในการตอบกลับการแก้ไขคำถาม:

1. "การใช้เซอร์วิส REST จะใช้เวลานานกว่าการใช้เซอร์วิส SOAP อย่างไม่มีที่สิ้นสุด"

   อืมไม่มีก็ไม่สามารถเพียบอีกต่อไป และในกรณีที่สิ่งที่คุณพยายามเรียกคืนเป็นเอกสารหรือไฟล์อยู่แล้วมันเร็วกว่ามาก ตัวอย่างเช่นข้อกำหนด OGC สำหรับ WMS (Web Mapping Service) กำหนดทั้งโปรโตคอล SOAP และ REST และมีเหตุผลที่เกือบจะไม่มีใครใช้รุ่น SOAP - เพราะถ้าคุณพยายามรับแผนที่ก็เป็นได้ ง่ายกว่ามากในการสร้าง URL และดึงข้อมูลภาพไบต์จาก URL นั้นมากกว่าการสร้างความรำคาญให้กับข้อความใน SOAP แต่ใช่ฉันจะยอมรับว่าถ้าจุดบริการเว็บคือการถ่ายโอนวัตถุที่พิมพ์อย่างรุนแรงบางอย่างในรูปแบบวัตถุโดเมน, SOAP เหมาะสำหรับการใช้งานที่ดีกว่า

2. "เหตุใดจึงต้องเขียนบริการ REST ที่ส่งคืน XML อยู่ดี"

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

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

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

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

4. "ฉันได้ยินข้อโต้แย้งว่าด้วย REST คุณสามารถป๊อปอัพ URL ในเบราว์เซอร์และดูข้อมูลได้"

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

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

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

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

สำหรับการบันทึกใช่ฉันได้พัฒนาเว็บเพจมาตั้งแต่ก่อนที่จะมี NetFlix หรือ Twitter และไม่ฉันยังไม่มีความต้องการหรือโอกาสใด ๆ ในการติดตั้งไคลเอนต์ไปยังบริการของ NetFlix หรือ Twitter แต่ถึงแม้ว่าการบริการของพวกเขาจะยากที่จะทำงานด้วยนั่นก็ไม่ได้หมายความว่าเทคโนโลยีที่พวกเขานำมาใช้ในการให้บริการนั้นไม่ดี - เฉพาะที่การติดตั้งทั้งสองนั้นไม่ดี

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

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

อย่างไรก็ตาม:

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

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

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

   แต่สำหรับ Twitter และ Netflix ไม่มีข้อตกลงสากลที่ว่า "ไมโครบล็อกทั้งหมดที่มีอยู่จะต้องใช้แอพพลิเคชั่นประเภทสื่อ / ทวีต" ส่วนใหญ่เป็นเพราะ microblogging เป็นเรื่องใหม่ บางทีในเวลาไม่กี่ปีที่ผ่านมาบริการไมโครบล็อกบางตัวก็ตั้งอยู่บน API เดียวกันดังนั้น Twitter, Facebook, Identica และสามารถทำงานร่วมกันได้ ไม่มี API ที่มีอยู่ของพวกเขาอยู่ใกล้ RESTful แต่พวกเขาอ้างสิทธิ์มากดังนั้นฉันไม่คาดหวังว่ามันจะเกิดขึ้นจริงเร็ว ๆ นี้

   " นอกจากนี้ในขณะที่ใช้งานบริการทั้งสองนี้คุณจะต้อง" คาดเดา "ว่าอะไรจะกลับมาที่ท่อเนื่องจากไม่มีสคีมาหรือเอกสารอ้างอิงจริง "

   คุณตีเล็บที่หัว ส่วนที่เหลือเป็นข้อมูลเกี่ยวกับการแจกจ่ายและสื่อหลายมิติ เบราว์เซอร์จะดูสิ่งที่ได้รับจากคำขอและแสดงให้ผู้ใช้เห็น หน้า HTML มักจะส่งคำขอ GET จำนวนมากเช่น CSS สคริปต์และรูปภาพ โดยทั่วไปรูปภาพจะแสดงผลไปยังหน้าจอเท่านั้น JavaScript ถูกเรียกใช้และอื่น ๆ ในแต่ละครั้งที่เบราว์เซอร์ไม่สิ่งที่มันไม่เพราะพบการเชื่อมโยงในนั้น<img>หรือ<style>แท็กและประเภทสื่อตอบสนองได้หรือimage/jpegtext/css

   หาก Twitter สร้าง API ที่ใช้ไฮเปอร์มีเดียมันอาจจะส่งคืนapplication/tweetทุกครั้งที่คุณติดตามลิงก์ไปยังทวีต แต่ลูกค้าไม่ควรถือว่ามันและตรวจสอบสิ่งที่ได้รับก่อนที่จะดำเนินการกับมัน

2. " เหตุใดจึงต้องเขียนบริการ REST ที่ส่งคืน XML อยู่ดี "

   สิ่งนี้ทำให้สื่อประเภทต่างๆแตกต่างกันไป เช่นเดียวกับ HTML หากคุณเห็นองค์ประกอบที่คุณไม่ทราบว่ามีความหมายจริงเพียงใดข้อมูลจำเพาะ HTML จะแนะนำให้คุณละเว้นพวกเขาและประมวลผล "เนื้อหา" ของแท็กหากมี อะตอมสเปคแนะนำให้คุณละเว้นองค์ประกอบที่ไม่รู้จักและมาร์กอัปต่างประเทศ (จากเนมสเปซที่แตกต่างกัน) และไม่ประมวลผลเนื้อหา (IIRC) เช่นเดียวกัน

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

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

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

4. " ฉันได้ยินข้อโต้แย้งว่าด้วย REST คุณสามารถป๊อปอัพ URL ในเบราว์เซอร์และดูข้อมูลได้ "

   ใช่นั่นเป็นเหตุผลที่ไม่ถูกต้องเช่นกัน มันไม่ทำงานอย่างนั้น แม้ว่าจะใช้งานได้ แต่REST APIs ที่แคบที่สุดก็ใช้ประเภทสื่อที่เบราว์เซอร์ไม่ทราบและยังคงใช้งานไม่ได้

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

5. " ทำไมเราต้องเป็น '' URL สำหรับแต่ละทรัพยากรหรือไม่ถ้าเราได้ใช้เครื่องมือในการใช้บริการที่เราทำจริงๆดูแลเกี่ยวกับ URL ที่แท้จริง? อ่าน "

   ถ้าคุณดูที่วิธีการที่เว็บการทำงานของผมค่อนข้างมั่นใจว่ามนุษย์โดยและขนาดใหญ่ดีใจที่ URI สำหรับหน้าวิกิพีเดียมีลักษณะเช่นนี้แทนhttp://en.wikipedia.org/wiki/Stack_overflow http://en.wikipedia.org/wiki/?oldid=376349090แต่ที่จริงแล้วมันไม่สำคัญสำหรับ REST สิ่งสำคัญในการพยายามทำให้ถูกต้องคือเลือกที่จะใส่ข้อมูลที่เกี่ยวข้องใน URI ที่ไม่น่าจะเปลี่ยนแปลง คุณอาจคิดว่า ID ฐานข้อมูลจะไม่เปลี่ยนแปลง แต่จะเกิดอะไรขึ้นเมื่อต้องรวมสองชุดข้อมูล คีย์หลักทั้งหมดของคุณเปลี่ยนไป ชื่อหน้า (Stack_overflow) จะไม่เปลี่ยนแปลง

ขออภัยสำหรับการตอบกลับที่ยาวนาน แต่ฉันเชื่อว่าคำถามนี้ใช้ได้และยังไม่ได้รับการแก้ไขก่อนหน้านี้ใน SO ฉันแน่ใจว่า Darrel Miller จะเพิ่มคำตอบของเขาเมื่อเขากลับมาด้วย

แก้ไข: การจัดรูปแบบ

Martin Fowler มีบทความเกี่ยวกับ Richardson Maturity Modelซึ่งสามารถอธิบายความแตกต่างระหว่าง SOAP และ REST ได้เป็นอย่างดี

WSDL และโปรโตคอลระดับเอกสารอื่น ๆ ซ้ำซ้อน โปรโตคอล HTTP รองรับชุดปฏิบัติการที่สมบูรณ์ยิ่งขึ้นนอกจากการให้บริการเอกสารและการส่งแบบฟอร์ม

ผู้สนับสนุนของ REST รู้สึกไม่สบายใจกับความซ้ำซ้อนนั้น