เหตุใดเราจึงต้องใช้บริการเว็บ RESTful


123

ฉันจะเรียนรู้บริการเว็บ RESTful (ดีกว่าที่จะบอกว่าฉันต้องทำสิ่งนี้เพราะเป็นส่วนหนึ่งของหลักสูตรปริญญาโท CS)

ฉันได้อ่านข้อมูลบางอย่างใน Wikipedia และฉันได้อ่านบทความเกี่ยวกับ REST ที่ Sun Developer Network และฉันเห็นว่ามันไม่ใช่เรื่องง่ายเทคโนโลยีมีกรอบพิเศษสำหรับการสร้างแอป RESTful และมักถูกเปรียบเทียบกับบริการเว็บ SOAP และ โปรแกรมเมอร์ควรเข้าใจว่าเมื่อใดควรใช้ SOAP และเมื่อใดที่ REST อาจเป็นแนวทางที่ดี

ฉันจำได้ว่าเมื่อหลายปีก่อน SOAP เป็นที่นิยมมาก (ทันสมัย?) และรายการ 'SOAP' จะต้องมีอยู่ในประวัติย่อที่ดีทุกรายการ แต่ในทางปฏิบัติมีการใช้น้อยมากและเพื่อให้บรรลุวัตถุประสงค์ที่เรียบง่าย

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

คุณช่วยยกตัวอย่างให้ฉันได้ไหมว่าควรใช้ REST และทำไมเราไม่สามารถทำแบบเดียวกันได้หากไม่มี REST (หรือทำไมเราควรใช้เวลามากขึ้นในการทำสิ่งเดียวกันโดยไม่มี REST)

UPD : โชคไม่ดีที่ฉันไม่เห็นข้อโต้แย้งที่เป็นรูปธรรมใด ๆ ที่สามารถทำให้ฉันนึกถึงในความคิดเห็นแรก ทำให้ฉันคิดว่า REST เป็นเทคโนโลยีที่ยอดเยี่ยม!

ฉันต้องการเห็นคำตอบดังนี้:

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

- โอ้เหี้ย! จอนนี่เราควรใช้ REST เพื่อใช้แอพนี้อย่างแน่นอน!
- ใช่บิลลี่เราสามารถใช้ REST ได้ แต่เราควรใช้ SOAP จะดีกว่า เชื่อฉันเถอะเพราะฉันรู้อะไรบางอย่างเกี่ยวกับการพัฒนาแอปพลิเคชัน HelloWorld
- แต่ SOAP เป็นเทคโนโลยีที่ล้าสมัยจากศตวรรษที่แล้วและเราสามารถใช้สิ่งที่ดีกว่าได้
- บิลลี่คุณพร้อมที่จะใช้เวลา 3 วันเพื่อทดลอง REST หรือยัง? เราสามารถทำได้ด้วย SOAP ภายใน 2 ชั่วโมง ..
- ใช่ฉันแน่ใจว่าเราจะใช้เวลามากขึ้นเพื่อให้บรรลุความปลอดภัย / ประสิทธิภาพ / / ความสามารถในการปรับขนาด / สิ่งอื่นใดด้วย SOAP เท่าเดิม ฉันแน่ใจว่าแอปพลิเคชัน HelloWorld ควรได้รับการพัฒนาเฉพาะกับ REST นับจากนี้


2
ไม่ใช่เทคโนโลยีที่ยอดเยี่ยม แต่เป็นเทคโนโลยีที่แตกต่างกัน หากคุณต้องการให้ใครมาโน้มน้าวคุณเป็นเรื่องที่ยอดเยี่ยมและควรใช้ทุกครั้งให้ลองใช้ที่ปรึกษา
quillbreaker

คำตอบ:


133

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

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

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

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

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

ประโยชน์ของสื่อสิ่งพิมพ์และการหลีกเลี่ยงของรัฐเซสชั่นทำให้สมดุลภาระง่ายและบริการแบ่งเป็นไปได้ การปฏิบัติตามกฎ HTTP อย่างเคร่งครัดทำให้เครื่องมือต่างๆเช่นดีบักเกอร์และแคชพร็อกซีเป็นสิ่งที่ยอดเยี่ยม

ปรับปรุง

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

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

คุณบอกว่าคุณไม่เคยเห็น REST ในทางปฏิบัติ แต่นั่นอาจเป็นจริงไม่ได้ถ้าคุณเคยใช้เว็บเบราว์เซอร์ เว็บเบราว์เซอร์เป็นไคลเอนต์ REST

  • เหตุใดคุณจึงไม่จำเป็นต้องทำการอัปเดตเบราว์เซอร์เมื่อมีคนเปลี่ยน html บางส่วนบนเว็บไซต์
  • เหตุใดฉันจึงสามารถเพิ่มชุดหน้าใหม่ทั้งหมดลงในเว็บไซต์ได้และ "ลูกค้า" ยังคงสามารถเข้าถึงหน้าใหม่เหล่านั้นได้โดยไม่ต้องอัปเดต
  • เหตุใดฉันจึงไม่จำเป็นต้องระบุ "service-description-language" ให้กับเว็บเบราว์เซอร์เพื่อบอกเมื่อไปที่http://example.org/images/catประเภทการส่งคืนจะเป็นรูปภาพ jpeg และเมื่อคุณไป ไปที่ http://example.org/description/cat ประเภทการส่งคืนจะเป็นข้อความ / html?
  • เหตุใดฉันจึงสามารถใช้เว็บเบราว์เซอร์เพื่อเยี่ยมชมไซต์ที่ไม่มีอยู่จริงเมื่อเปิดตัวเบราว์เซอร์ ลูกค้าจะรู้เกี่ยวกับไซต์เหล่านี้ได้อย่างไร?

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

StackOverflow ใช้บริการ OpenId ที่หลากหลายสำหรับการตรวจสอบสิทธิ์ gravatar.com สำหรับภาพอวาตาร์การวิเคราะห์ของ Google และ Quantserve สำหรับข้อมูลเชิงวิเคราะห์ การรวมหลาย บริษัท แบบนี้เป็นสิ่งที่โลก SOAP ฝันถึงเท่านั้น หนึ่งในตัวอย่างที่ดีที่สุดคือความจริงที่ว่าไลบรารี jQuery ที่ใช้ในการขับเคลื่อน StackOverflow UI นั้นถูกดึงมาจาก Content Delivery Network ของ Google ความจริงที่ว่า SO สามารถสั่งให้ไคลเอนต์ (เช่นเว็บเบราว์เซอร์ของคุณ) ดาวน์โหลดโค้ดจากไซต์ของบุคคลที่สามเพื่อปรับปรุงประสิทธิภาพเป็นข้อพิสูจน์ถึงการมีเพศสัมพันธ์ที่ต่ำระหว่างเว็บไคลเอ็นต์และเซิร์ฟเวอร์

นี่คือตัวอย่างของสถาปัตยกรรม REST ในที่ทำงาน

ขณะนี้บางเว็บไซต์ / แอปพลิเคชันทำผิดกฎของ RESTและเบราว์เซอร์ไม่ทำงานตามที่คาดไว้

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

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


@ Darrell: REST ลดการมีเพศสัมพันธ์ผ่าน SOAP ในโลกได้อย่างไร? หรือ SOAP เพิ่มการมีเพศสัมพันธ์เหนือ REST ได้อย่างไร คุณกำลังอ้างถึงข้อเท็จจริงที่ว่าไคลเอนต์ SOAP จำเป็นต้องเข้าใจ SOAP จริง ๆ แต่ไคลเอนต์ REST จำเป็นต้องเข้าใจประเภทสื่อเท่านั้นหรือไม่?
John Saunders

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

@ John REST พยายามสร้างมาตรฐานโปรโตคอลการโต้ตอบกับความหมายของคำกริยา HTTP รูปแบบข้อมูลไปยังประเภทที่ลงทะเบียน IANA และจุดสิ้นสุดทั้งหมดควรจะค้นพบได้แบบไดนามิก นั่นหมายความว่าการเชื่อมต่อไคลเอ็นต์ / เซิร์ฟเวอร์ถูกแปลตามนิยามของประเภทสื่อ เช่นเดียวกับที่ Rich กล่าวว่า "บริการของคุณ จำกัด ขอบเขตของการมีเพศสัมพันธ์ให้แคบลงเหลือเพียงสิ่งเดียวนั่นคือประเภทสื่อ"
Darrel Miller

@ Darrell: นั่นไม่ใช่การมีเพศสัมพันธ์ในความหมายดั้งเดิม ไคลเอนต์อาจได้รับการพิจารณาว่าเป็น "คู่" กับข้อมูลเมตา (WSDL) แต่ไม่ใช่สำหรับบริการ พิจารณาบริการที่ส่งคืน "พนักงาน": {int id; สตริง firstName, lastName, streetAddress1, streetAddress2, เมือง, รัฐ; int zip;}. ดูเหมือนคุณจะแนะนำให้เราลงทะเบียน "พนักงาน" กับ IANA หรือว่าเราแค่ถือว่า "Employee" เป็นอาร์เรย์ของคู่ชื่อ / ค่าที่เชื่อมโยงกัน
John Saunders

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

11

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

ที่ด้านบนของวิทยานิพนธ์มีข้อความอ้างอิง:

เกือบทุกคนรู้สึกสงบกับธรรมชาติ: ฟังเสียงคลื่นทะเลกระทบชายฝั่งริมทะเลสาบนิ่งในทุ่งหญ้าบนทุ่งหญ้า วันหนึ่งเมื่อเราได้เรียนรู้วิถีทางเหนือกาลเวลาอีกครั้งเราจะรู้สึกเช่นเดียวกันกับเมืองของเราและเราจะรู้สึกสงบสุขในเมืองเหล่านั้นให้มากที่สุดเหมือนที่เราทำในวันนี้ที่เดินริมทะเลหรือนอนเหยียดยาวบนผืนหญ้ายาวของ ทุ่งหญ้า

- คริสโตเฟอร์อเล็กซานเดอร์วิถีแห่งการสร้างเหนือกาลเวลา (2522)

และนั่นก็สรุปได้ตรงนี้ REST มีความสง่างามกว่าในหลาย ๆ ด้าน

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


SOAP ถูกกำหนดย้อนกลับไปในปี 1998 "อนุสัญญา" HTTP ในตอนนั้นมีกี่อนุสัญญา?
John Saunders

ตามw3.org/Protocols/HTTP/1.0/spec.html HTTP นี้ถูกใช้งานตั้งแต่ปี 1990 แล้วไงล่ะ? เราทุกคนรู้ว่าเหตุผลเดียวที่ SOAP ใช้ http คือเพราะพอร์ต 80 มักจะเปิดบนไฟร์วอลล์ Microsoft จะไม่ทำผิดพลาด DCOM อีกครั้ง
Darrel Miller

1
" REST สร้างด้วย HTTP แทนที่จะอยู่ด้านบน " +1 เธรดทั้งหมดนี้มีประโยชน์มากสำหรับฉันในการทำความเข้าใจความถูกต้องของการใช้ REST บน SOAP และในทางกลับกัน
ริส 22

9

จากที่นี่ :

ข้อดีของ REST:

  • น้ำหนักเบา - มาร์กอัป xml พิเศษไม่มากนัก
  • ผลลัพธ์ที่มนุษย์อ่านได้
  • สร้างง่าย - ไม่ต้องใช้ชุดเครื่องมือ

ตรวจสอบสิ่งนี้ด้วย:

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


4
ความคิดเห็นข้อเสียไม่ถูกต้องมาก การย้ายพารามิเตอร์จาก URI เข้าสู่ร่างกายถือว่ายังไม่ปลอดภัย ใช้ SSL เพื่อความปลอดภัย นอกจากนี้เมื่อข้อมูลใน uri อาจมีความยาวมากคุณได้รับอนุญาตให้ใช้โพสต์และวางไว้ในเนื้อหา ภาษาฝั่งเซิร์ฟเวอร์ส่วนใหญ่รวมข้อมูลจากพารามิเตอร์ URI และพารามิเตอร์ POST ดังนั้นจึงไม่จำเป็นต้องมีการเปลี่ยนแปลงบนเซิร์ฟเวอร์
Emil Ivanov

1
@Emil - โปรดทราบว่า SSL ไม่สามารถใช้ได้ตลอดเวลา บางคนต้องการความปลอดภัยตามข้อความและไม่ใช่การรักษาความปลอดภัยตามระดับการขนส่ง และเท่าที่ใช้เนื้อความของ POST ... POST เป็นหนึ่งในคำกริยาที่ใช้ในการประมวลผลคำขอ REST คุณไม่สามารถนำกลับมาใช้ใหม่ให้เหมาะกับความต้องการของคุณได้เสมอไป
Justin Niessner

1
CON ขนาดใหญ่: ไม่มีภาษา "คำอธิบาย" ที่เป็นมาตรฐานเช่น WSDL สำหรับบริการ SOAP - บริการ REST ทุกรายการอาจมีหรือไม่มีเอกสารประกอบและคุณภาพของเอกสารจะแตกต่างอย่างมากจากการให้บริการอื่น ๆ .....
marc_s

3
@Marc_s หาก REST ทำอย่างถูกต้องไม่จำเป็นต้องมี "ภาษาคำอธิบาย" เช่น WSDL ประเภทสื่อที่ใช้จำเป็นต้องได้รับการจัดทำเป็นเอกสาร แต่ไม่ควรมีเอกสารประกอบที่เชื่อมโยงจุดสิ้นสุดกับประเภทสื่อ
Darrel Miller

@ Darrel: ฉันขอโทษฉันไม่ได้ซื้อเรื่องไร้สาระ "no description language" แม้ว่าประเภทเอกสารจะได้รับการจัดทำเป็นเอกสาร แต่ก็จำเป็นต้องอธิบายด้วย นอกจากนี้บางคนชอบที่จะแยกเนื้อหาออกเป็นวัตถุในภาษาโปรแกรม ในกรณีนี้การมีคำจำกัดความที่เครื่องสามารถอ่านได้ว่าบริการสามารถส่งและรับอะไรได้ดังนั้นเครื่องมือของคุณจึงสามารถสร้างคลาสที่เกี่ยวข้องและรหัสซีเรียลไลเซชันได้
John Saunders

8

ฉันสามารถพูดได้อย่างปลอดภัยว่าฉันใช้เวลามากในการทำความเข้าใจสิ่งนี้ในฐานะมือใหม่ แต่นี่เป็นลิงค์ที่ดีที่สุดในการเริ่มต้นด้วย REST ตั้งแต่เริ่มต้น! http://www.codeproject.com/Articles/21174/Everything-About-REST-Web-Services-What-and-How-Pa

เพียงเพื่อดึงคุณเข้ามา

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

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

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

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

คุณต้องคิดว่ามันช่วยคุณในฐานะลูกค้าได้อย่างไรในการรับสภาพอากาศของดัลลัส เราจะไปถึงจุดนั้นในอีกสักครู่

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

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


ประโยชน์ของการมี object แทน method คืออะไร?
Soumya Rauth

4

นี่คือแนวคิดบางส่วน:

  • REST จำกัด บริการของคุณให้ใช้อินเทอร์เฟซที่เหมือนกัน คุณไม่จำเป็นต้องเสียเวลาฝันกลางวัน (หรือโต้เถียง) เกี่ยวกับวิธีการทั้งหมดที่อาจเป็นไปได้ที่บริการของคุณจะทำงานได้ - คุณมีสิทธิ์ในการระบุทรัพยากรในระบบของคุณ กลายเป็นงานใหญ่ในตัวเอง แต่โชคดีที่ปัญหามักจะถูกกำหนดไว้ได้ดีกว่ามาก
  • ด้วยทรัพยากรความสัมพันธ์และตัวแทนที่มีอยู่ในมือการใช้บริการของคุณมีน้อยมากเนื่องจากมีการตัดสินใจหลายอย่างให้คุณ
  • ระบบของคุณจะดูเหมือนระบบ RESTful อื่น ๆ มาก เส้นโค้งการเรียนรู้สำหรับเพื่อนร่วมทีมคู่ค้าและลูกค้าจะลดลง
  • คุณจะมีคำศัพท์ทั่วไปเพื่อพูดคุยเกี่ยวกับปัญหาการออกแบบกับนักพัฒนาคนอื่น ๆ และแม้กระทั่งกับผู้ที่ไม่ค่อยมีความคิดทางเทคนิค (เช่นลูกค้า)
  • ดังที่ Darrel กล่าวเนื่องจากคุณใช้การออกแบบที่ขับเคลื่อนด้วยไฮเปอร์เท็กซ์บริการของคุณจึง จำกัด ขอบเขตของการเชื่อมต่อให้เหลือเพียงสิ่งเดียวนั่นคือประเภทสื่อ สิ่งนี้ช่วยคุณในฐานะนักพัฒนาเนื่องจากการเปลี่ยนแปลงในระบบของคุณมีอยู่ในกลุ่มผู้ติดต่อที่แคบ ซึ่งจะช่วยลูกค้าของคุณในการที่การเปลี่ยนแปลงของคุณน้อยลงจะทำให้โค้ดของพวกเขาเสียหาย
  • เกือบทุกปัญหาที่คุณอาจมีในการใช้ REST สามารถแก้ไขได้โดยการเปิดเผยทรัพยากรใหม่หรือคิดแบบจำลองทรัพยากรของคุณใหม่ โฟกัสนี้คือ IMO ซึ่งเป็นการเพิ่มประสิทธิภาพการทำงานที่ยิ่งใหญ่

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


@ จอห์นถ้าฉันยิง VS และสร้างโปรเจ็กต์ WCF และสร้างอินเทอร์เฟซด้วยแอตทริบิวต์ [ServiceContract] ฉันสามารถเพิ่มการเรียกเมธอดใดก็ได้ที่ฉันชอบ CreateCustomer (), MakeOrder (), ConfirmOrder (), VerifyOrder (), SubmitOrder (), CheckStockAvailability (), CancelOrder () จากวิธีการเหล่านั้นคุณสามารถบอกฉันได้ไหมว่าลำดับใดที่ฉันควรใช้ในการประมวลผลคำสั่งซื้อ บอกได้ไหมว่าฉันได้รับอนุญาตให้โทร CancelOrder () เมื่อใด ฉันควรตรวจสอบความพร้อมก่อนยืนยันคำสั่งซื้อหรือไม่ ฉันควรตรวจสอบคำสั่งซื้อก่อนตรวจสอบความพร้อมหรือไม่? อินเตอร์เฟซนี้ไม่น่าจะสอดคล้องกับการทำบัญชีเงินเดือน
Darrel Miller

1
@ Darrel: ฉันไม่เห็นว่า REST ช่วยแก้ปัญหานี้ได้อย่างไร ไม่MakeOrderให้ออก URL ของConfirmOrderและCancelOrder? ลูกค้าไม่รู้วิธีเรียกใช้บริการ แต่ต้องการข้อมูลเป็นหลักหรือไม่?
John Saunders

1
@ จอห์นเป๊ะ. ลูกค้าทราบว่าอาจมีการระบุ url ConfirmOrder และ CancelOrder แต่ไม่ทราบว่า URL เหล่านั้นมีลักษณะอย่างไรและจะปฏิบัติตามหากมีให้เท่านั้น คุณเรียกว่าข้อมูลเป็นตัวขับเคลื่อน Roy เรียกมันว่า Hypermedia เป็น Engine of Application State
Darrel Miller

@Darrel: ฉันเดาว่าฉันไม่เคยเห็นบริการที่มีความสำคัญทางธุรกิจใด ๆ ที่ฉันต้องการกำหนดว่าจะโทรอะไรต่อไปโดยพิจารณาจาก URL ที่ฉันส่งผ่านจากการโทรครั้งก่อน
John Saunders

1
@JohnSaunders: นั่นเป็นเพราะการโทร REST ไม่ได้เกี่ยวกับการเรียกใช้เมธอด แต่เป็นการเปลี่ยนสถานะ (คิดว่าเครื่องสถานะ) ในสถานะใด ๆ เซิร์ฟเวอร์ RESTful จะระบุการเปลี่ยนสถานะที่ถูกต้องและผู้ใช้หรือตัวแทนผู้ใช้จะเลือกการเปลี่ยนที่ต้องการติดตาม
Lie Ryan

4

คำตอบ "มืออาชีพ" ส่วนใหญ่เกี่ยวกับ REST ดูเหมือนจะมาจากผู้ที่ไม่เคยพัฒนาบริการเว็บ SOAP หรือไคลเอนต์โดยใช้สภาพแวดล้อมที่จัดหาเครื่องมือที่เหมาะสมสำหรับงาน พวกเขาบ่นเกี่ยวกับปัญหาที่ฉันไม่เคยพบมาก่อนโดยใช้ Visual Studio .NET และ Rational Web Developer ของ IBM ฉันคิดว่าหากคุณต้องพัฒนาบริการบนเว็บหรือไคลเอนต์ในภาษาสคริปต์หรือภาษาอื่น ๆ ที่มีการสนับสนุนเครื่องมือเพียงเล็กน้อยหรือไม่มีเลยนั่นเป็นข้อร้องเรียนที่ถูกต้อง

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


ตัวอย่างที่ดีที่สุดที่เปิดเผยต่อสาธารณะจนถึงปัจจุบันคือ Sun Cloud API นี่คือคำแนะนำkenai.com/projects/suncloudapis/pages/… เพียงเพื่อรับรองประสบการณ์ของฉันกับ SOAP ฉันได้สร้างและยังคงสนับสนุนบริการเว็บ ASMX โดยใช้โรงงานซอฟต์แวร์บริการเว็บของ Microsoft จากกลุ่ม Patterns and Practices ฉันได้สร้างบริการที่ใช้ WCF โดยใช้ซอฟต์แวร์จากโรงงานเดียวกันในภายหลัง ฉันยังใช้ System.ServiceModel.Web ของ WCF ตั้งแต่เปิดตัวครั้งแรกด้วย Biztalk Services SDK ในเดือนพฤษภาคม 2550
Darrel Miller

1
John- ตัวอย่างหนึ่งของ API ที่เหลือคือ Amazon มีทั้ง @SOAP และ REST API มันอาจจะมีประโยชน์สำหรับ you- docs.amazonwebservices.com/AmazonS3/latest/...
RichardOD

3

หากต้องการเพิ่มการหมุนที่ไม่เป็นทางการเล็กน้อยให้กับคำตอบที่ได้รับแล้วด้วยเหตุผลที่เราใช้บริการ REST ในที่ที่ฉันอยู่คือถ้าคุณรู้ว่าคุณสามารถมอบ URL ให้พันธมิตรทางธุรกิจและรู้ว่าพวกเขาจะได้รับในทางกลับกันแผ่น XML ที่วางไว้อย่างสวยงาม ไม่ว่าพวกเขาจะทำงานใน. Net xx, PHP, Python, Java, Ruby หรือสิ่งที่พระเจ้ารู้ก็ช่วยลดอาการปวดหัวได้อย่างมาก

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

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

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

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


3

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

ในหลาย ๆ ด้าน World Wide Web เองที่ใช้ HTTP สามารถถูกมองว่าเป็นสถาปัตยกรรมที่ใช้ REST แอปพลิเคชัน RESTful ใช้คำขอ HTTP เพื่อโพสต์ข้อมูล (สร้างและ / หรืออัปเดต) อ่านข้อมูล (เช่นสร้างแบบสอบถาม) และลบข้อมูล ดังนั้น REST จึงใช้ HTTP สำหรับการดำเนินการ CRUD (สร้าง / อ่าน / อัปเดต / ลบ) ทั้งสี่

REST เป็นทางเลือกที่มีน้ำหนักเบาสำหรับกลไกเช่น RPC (Remote Procedure Calls) และ Web Services (SOAP, WSDL และอื่น ๆ ) ต่อมาเราจะมาดูกันว่า REST ง่ายกว่ามากแค่ไหน

แม้จะเรียบง่าย แต่ REST ก็มีคุณสมบัติครบถ้วน โดยพื้นฐานแล้วไม่มีอะไรที่คุณสามารถทำได้ใน Web Services ที่ไม่สามารถทำได้ด้วยสถาปัตยกรรม RESTful REST ไม่ใช่ "มาตรฐาน" จะไม่มีการแนะนำข้อมูล W3C สำหรับ REST เช่น และในขณะที่มีเฟรมเวิร์กการเขียนโปรแกรม REST การทำงานกับ REST นั้นง่ายมากจนคุณสามารถ "ม้วนของคุณเอง" ด้วยคุณสมบัติไลบรารีมาตรฐานในภาษาต่างๆเช่น Perl, Java หรือ C #


" ในหลาย ๆ วิธี World Wide Web เองที่ใช้ HTTP สามารถมองได้ว่าเป็นสถาปัตยกรรมที่ใช้ REST แอปพลิเคชัน RESTful ใช้คำขอ HTTP เพื่อโพสต์ข้อมูล (สร้างและ / หรืออัปเดต) อ่านข้อมูล (เช่นสร้างแบบสอบถาม) และลบข้อมูลดังนั้น REST จึงใช้ HTTP สำหรับการดำเนินการ CRUD (สร้าง / อ่าน / อัปเดต / ลบ) ทั้งสี่ "นี่เป็นอีกตัวอย่างที่ใช้ได้จริงสำหรับฉันที่จะนำออกจากโพสต์นี้ ขอบคุณ.
ริส 22
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.