ทำไมคนเราถึงใช้ REST แทนการให้บริการแบบ SOAP? [ปิด]

เข้าร่วมการสาธิตที่น่าสนใจเกี่ยวกับ REST ในวันนี้อย่างไรก็ตามฉันไม่สามารถนึกถึงเหตุผลเดียว (หรือไม่มีการนำเสนอ) ทำไม REST ถึงดีกว่าหรือง่ายกว่าในการใช้งาน

อะไรคือสาเหตุที่ทำให้ทุกคนใน "โลกแห่งความจริง" ใช้ REST แทน SOAP based Services?

ค่าใช้จ่ายน้อยลง (ไม่มีซอง SOAP ที่จะรวมการโทรทุกครั้ง)

การทำซ้ำน้อยกว่า (HTTP แสดงการดำเนินการเช่น DELETE, PUT, GET และอื่น ๆ ที่ต้องแสดงเป็นซอง SOAP)

เป็นมาตรฐานมากขึ้น - การดำเนินการ HTTP เข้าใจและใช้งานได้ดีอย่างต่อเนื่อง การใช้งาน SOAP บางอย่างจะได้รับการพิถีพิถัน

มีคนอ่านและทดสอบได้มากขึ้น (ยากที่จะทดสอบ SOAP ด้วยเบราว์เซอร์)

ไม่จำเป็นต้องใช้ XML (เช่นคุณไม่จำเป็นต้องใช้ SOAP เช่นกัน แต่มันก็ไม่ค่อยสมเหตุสมผลนักเนื่องจากคุณกำลังแยกวิเคราะห์ซองจดหมายอยู่แล้ว)

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

บริการRESTfulนั้นง่ายต่อการใช้งานมากกว่าบริการSOAP (ปกติ) เหตุผลสำหรับเรื่องนี้คือ REST ขึ้นอยู่กับคำขอ HTTP ปกติซึ่งเปิดใช้งานเจตนาที่จะอนุมานจากประเภทของคำขอที่กำลังทำ (GET = retrive, POST = เขียน, DELETE = ลบ, ฯลฯ ... ) และไม่มีสัญชาติทั้งหมด ในอีกทางหนึ่งคุณสามารถยืนยันว่ามันมีความยืดหยุ่นน้อยลงตามแนวคิดของซองข้อความที่มีบริบทคำขอ

จากประสบการณ์ของฉัน SOAP เป็นที่ต้องการสำหรับบริการภายในองค์กรและ REST เป็นที่ต้องการสำหรับบริการที่เปิดเผยว่าเป็น API สาธารณะ

ด้วยเครื่องมืออย่าง WCF ใน. NET Framework มันเป็นเรื่องง่ายมากที่จะใช้บริการเป็น REST หรือ SOAP

การอ่านที่เกี่ยวข้องบางส่วน:

• บล็อก Amazon Web Services: REST กับสบู่
• Dare Obasanjo มักเขียนเกี่ยวกับ REST

ฉันจะสมมติว่าเมื่อคุณพูดว่า "บริการเว็บ" คุณหมายถึง SOAP และชุดมาตรฐาน WS- * (มิฉะนั้นฉันสามารถยืนยันได้ว่าบริการ REST คือ "บริการบนเว็บ")

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

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

ค่าใช้จ่ายไม่สำคัญเท่าสถาปัตยกรรมที่ดี

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

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

REST นั้นไม่เชื่อเรื่องการนำไปปฏิบัติและโปร่งใสมากขึ้นและนี่ก็เป็นสิ่งที่ดีสำหรับ API สาธารณะโดยเฉพาะอย่างยิ่งสำหรับเว็บไซต์ขนาดใหญ่เช่น Flickr, Amazon หรือ Digg ที่ใช้ API ของพวกเขาเป็นเครื่องมือทางการตลาดและต้องการให้ผู้คนบริโภคข้อมูลของพวกเขา พวกเขาไม่ต้องการถือนักพัฒนามือใหม่จำนวน 1,000 คนที่พยายามดีบักภาษาสคริปต์ของไลบรารี SOAP buggy ของตัวเลือก

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

ต้องอ่านวิทยานิพนธ์ที่ยอดเยี่ยมที่สุดของ Roy Fielding ในหัวข้อนี้ เขาทำให้กรณีที่ยอดเยี่ยมและเป็นมั่นเหมาะWAYก่อนเวลาของเขาเมื่อเขาเขียนมัน (2000)

บล็อกของ Steve Vinoskiและบทความล่าสุดของเขามีค่าน่าอ่านอย่างแน่นอน เขาเป็นกูรู CORBA อดีตผู้เขียนอาจจะเป็นหนังสือที่ดีที่สุดเกี่ยวกับเรื่องที่มี Michi เฮนนิ่ง"ขั้นสูงCORBA®การเขียนโปรแกรมด้วยภาษา C ++" อย่างไรก็ตามเขาได้เห็นข้อผิดพลาดของลูกค้า / เซิร์ฟเวอร์ของเขาและตอนนี้สาบานโดย REST

ส่วนที่เหลือจะช่วยให้คุณดำเนินการไม่กรรมวิธี (ที่มักใช้คำกริยาการ GET) จะถูกเก็บไว้ชั่วคราว นั่นคือแคชโดยลูกค้าและ / หรือแคชโดยผู้รับมอบฉันทะ นี่เป็นชัยชนะครั้งใหญ่!

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

http://www.xfront.com/REST-Web-Services.html http://en.wikipedia.org/wiki/Representational_State_Transfer

มันง่ายและบางสุด ๆ คุณสามารถทำได้ด้วยเบราว์เซอร์ผ่านทางคำกริยา http: GET ฉันไม่พบเบราว์เซอร์ที่สามารถทำคำขอ http POST ทั่วไปได้ด้วยตนเองอย่างง่ายดาย

นี่คือจุดข้อมูลหนึ่งจุด: Amazon เสนอ APIs ในรูปแบบ REST และ SOAP และ 85% ของการใช้คือ REST

REST นั้นง่ายต่อการใช้งานง่ายต่อการเข้าใจและประสิทธิภาพที่สูงขึ้น