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

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

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

โดยพื้นฐานแล้วฉันรู้สึกว่าคำอธิบายของโครงสร้างทรัพยากรด้านเซิร์ฟเวอร์นั้นเทียบเท่ากับคำนิยามของคำศัพท์ แต่จากนั้นเราถูกบังคับให้ใช้คำศัพท์ที่มีข้อ จำกัด ในการโต้ตอบกับทรัพยากรเหล่านี้

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

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

การสะท้อนกลับ

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

คำศัพท์ "กริยา" และ "คำนาม" ค่อนข้างโชคร้ายที่นี่ ดังที่คุณได้กล่าวไปแล้วคุณสามารถสร้างวัตถุสำหรับฟังก์ชั่นได้อย่างง่ายดาย ภาษาเชิงวัตถุทั้งหมดยกเว้น Java มีการแปลงในตัวและใน Java คุณจะต้องทำมันตลอดเวลาอย่างไรก็ตามท้ายสุดแล้วมีวัตถุจำนวนมากที่มีวิธีการเดียวและมักจะเรียกว่า "เรียกใช้", "เรียกใช้", "ใช้" หรือ somesuch (ดังนั้นจึงเป็นภาษาการเขียนโปรแกรมที่ความแตกต่างของ "กริยา" / "คำนาม" ไม่สมเหตุสมผล)

"คำกริยา" ของ REST นั้นเหมือนกับการแบ่งประเภทวิธีการของคุณไปที่ getters, setters (deleters; ถือได้ว่าเป็น setters) และอื่น ๆ และพยายามทำทุกอย่างกับผู้ตั้งตัวและผู้ตั้งค่า เหตุผลนี้คือ:

1. ความหมายที่ง่ายกว่าเมื่อเผชิญกับความล้มเหลวในการสื่อสารเนื่องจากทั้ง getters และ setters เป็น idempotent การรับทรัพยากรสองครั้งไม่มีผลกระทบเพิ่มเติมและไม่ตั้งเป็นค่าที่มีอยู่แล้ว
2. การกำหนดซีแมนทิกส์บางอย่างที่สามารถใช้ได้โดยการแคชพร็อกซีที่อาจไม่เข้าใจอินเตอร์เฟสเฉพาะ Getters จะถูกแคชและ setters เป็นที่รู้จักกันในการทำให้แคชใช้ไม่ได้

HTTP ได้รับการออกแบบมาตั้งแต่เริ่มแรกโดยคำนึงถึงแคชและความทนทานต่อความผิดดังนั้นทั้งสองจุดนี้นำไปสู่วิธีการพื้นฐานสี่วิธี:

• GETเป็นทะเยอทะยาน มันจะไม่เปลี่ยนแปลงสถานะเซิร์ฟเวอร์และคืนค่าเดิมทุกครั้งที่มีความเป็นไปได้ในการระบุนโยบายการหมดอายุและการตรวจสอบความถูกต้องอีกครั้ง
• PUTและDELETEเป็น setter และ deleter (= setter กับศูนย์) โดยปกติจะไม่ใช้ในบริบทของเว็บปกติ แต่ควรใช้กับ REST
• POST เป็นอ่างล้างจานทั่วไปที่เรียกใช้ซึ่งแคชไม่สามารถสันนิษฐานได้

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

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

แนวคิดที่สำคัญคือความซับซ้อนแสดงผ่านการแทนทรัพยากรและไม่จำเป็นต้องใช้คำกริยาเพิ่มเติม ตามที่บางคนกล่าวไว้ - "ใน REST คำนามเป็นสิ่งที่ดีคำกริยาไม่ดี"

ถ้าคุณดูกริยา REST สี่คำกริยาเหล่านั้นสามารถถูกแมปกับการดำเนินการ CRUD ขั้นพื้นฐานซึ่งช่วยให้คุณทำสิ่งที่คุณต้องการด้วยทรัพยากรของคุณ นั่นคือ -

POST - สร้างทรัพยากร

GET - อ่านทรัพยากร

PUT - อัปเดตทรัพยากร

DELETE - ลบทรัพยากร

คุณต้องการอะไรอีก

พิจารณาภาษาที่โครงสร้างทั้งหมด (เช่นฟังก์ชั่น) เป็นวัตถุ จากนั้นคำกริยา RESTful ก็แค่เรียกการประชุมและงบการมอบหมาย สำหรับ JavaScript คุณสามารถกำหนดไวยากรณ์คำกริยาคงที่เช่น INVOKE สำหรับการเรียกใช้ฟังก์ชัน DELETE (เหมือนกับการลบใน js) สำหรับการลบวัตถุบนวัตถุอื่น SET สำหรับการกำหนดค่าและ RETURN สำหรับการคืนค่า เราสามารถใช้คำกริยา HTTP เพื่อหมายถึงฟังก์ชัน POST - invoke ที่เทียบเท่า, PUT - กำหนดค่า, GET - ส่งกลับค่า, - ลบ - ลบวัตถุ ฉันจมอยู่กับความคิดที่ว่าวิธีการ HTTP นั้นได้อธิบายถึงวิธีวัตถุจริง ๆ แล้วส่วนต่อประสานวัตถุจริงที่ฉันล้มเหลวที่จะเห็นว่ามันสามารถอธิบายแนวความคิดระดับต่ำกว่าได้มากเช่นการสร้างภาษาพื้นฐานที่ชัดเจนและแน่นอน ภาษามีเหตุผล

และแน่นอนว่ามันมีประโยชน์สำหรับการกำหนดเส้นทาง / พร็อกซี่ที่จะมีคำศัพท์ที่คงที่เพื่อสะท้อน

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

• เนื่องจากไม่จำเป็นต้องมีมาตรฐานเกี่ยวกับชื่อเมธอดเมื่อกำหนดไว้แล้ว

• เพราะจุดประสงค์หลักของรหัสนั้นสามารถอ่านได้โดยไม่ต้องมีการแปลเพิ่มเติม

• เพราะมันส่งเสริมและช่วยในการระบุ 'เมื่อ' คลาสอื่นควรจะแตกออก

• เมื่อคุณรับรหัสมันสมเหตุสมผลและจริง ๆ แล้วเป็นไปได้ที่จะเข้าใจว่าอะไรและมันเร็วกว่ามากแค่ไหน

• มันมีคำศัพท์ทั่วไปและระดับของการทำให้เป็นนามธรรมเพื่อให้คุณสามารถมุ่งเน้นไปที่รายละเอียดอื่น ๆ และดูรูปแบบ

• มันทำให้การค้นหาข้อผิดพลาดง่ายขึ้นเนื่องจากมีการตรวจสอบรหัสและแนวทางทั่วไปได้ง่าย

• เมื่อคุณทำงานกับ 'เลเยอร์' หลายรายการเช่นที่ทำในการพัฒนาเว็บการรู้ว่า URL ใดตรงกับชื่อการกระทำที่มีประโยชน์มากสำหรับการดีบัก

โดยรวมแล้วคุณไม่จำเป็นต้อง 'เสมอ' แต่เหมือนมาตรฐานส่วนใหญ่มันสมเหตุสมผลดีที่จะพยายามใช้มัน!

ทางเลือกคือสิ่งที่น่ากลัว: WSDL (aka Web Service Definition Language) ซึ่งเป็นวิธี (งุ่มง่าม) ในการอธิบายโดยทางโปรแกรม (ค่อนข้าง) โดยพลการ APIS

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

มีพอดคาสต์ซึ่งเป็นสเตฟาน Tilkov อธิบาย REST อย่าง

ใช่ api ที่เหลือมีชุดคำกริยาคงที่ แต่ไม่จำเป็นต้อง จำกัด (หรือรวม GET, POST, PUT, DELETE) ฉันจะดู GET, POST, PUT, DELETE เป็นการใช้งานเริ่มต้นของ REST ซึ่งทำงานได้ 80% ของระบบทั้งหมดที่อยู่ในนั้น

ระบบอื่น ๆ ที่นำมาใช้มากกว่าการดำเนินงานที่ไม่รัดกุมสามารถ (และทำ) ใช้คำกริยาของตนเองสำหรับ REST API คำกริยาเช่น Publish, Consume, Rate, Comment, Search, Browse สามารถเพิ่มและนำไปใช้ในระบบ REST ในขณะที่บางคนอาจบอกว่าคำศัพท์ที่มีขนาดใหญ่อาจทำให้มันซับซ้อนขึ้นคำตอบของฉันคือมันขึ้นอยู่กับ หากผู้ใช้เป้าหมายของคุณเป็นหัวหน้าฝ่ายเทคโนโลยีที่เข้าใจว่า POST คืออะไรใช่ว่ามันอาจซับซ้อนกว่า อย่างไรก็ตามหากผู้ใช้เป้าหมาย API ของคุณเป็นคนจริง (เช่นคนที่ไม่ได้รหัสและไม่รู้ว่า POST คืออะไร) คำกริยาจริงนั้นใช้งานได้ง่ายกว่ามาก ในความเป็นจริงการมีชุดคำกริยาที่เหมาะสมสำหรับ API ของคุณช่วยให้ URL สั้น (ซึ่งเป็นสิ่งสำคัญหากคุณต้องการให้ผู้ใช้พิมพ์ในเบราว์เซอร์ถ้าคุณใช้คำศัพท์ที่กำหนดเองคุณ ต้องการให้แน่ใจว่า API และคำกริยาของคุณได้รับการบันทึกไว้อย่างดี เมื่อใช้ REST api ที่กำหนดเองคุณต้องแน่ใจว่า 'อ่านอย่างเดียว' เป็น HTTP GET และ 'เขียนการกระทำ' ด้วย POST

Piczo.com ซึ่งเป็นเครือข่ายสังคมสำหรับวัยรุ่น (ขอให้พักอย่างสงบ) นำเสนอ REST API แบบขยาย (รวมถึงคำกริยาที่กล่าวถึงข้างต้น) ซึ่งมีการใช้งานใน 7 ภาษา!

เรียบง่ายเป็นสิ่งที่ดี

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

object.foo () ดีทั้งหมด แต่ทำอะไรได้บ้าง มันคืออะไรกลับมา? มันคือการปรับเปลี่ยนสถานะของวัตถุหรือการอ้างอิงใด ๆ ? คุณสามารถเรียกมันสองครั้งแล้วได้ผลลัพธ์เดียวกันหรือมันจะให้สองค่าที่ต่างกันหรือไม่? หากคุณมี object.bar () เช่นกันพวกเขาจำเป็นต้องถูกเรียกตามลำดับที่ระบุหรือไม่

มีความรู้จำนวนมากที่ต้องใช้ในการใช้ API ที่หลากหลายและพวกเขามักจะมีแบบแผนของตัวเอง (เช่น setFoo กำลังจะกลายพันธุ์วัตถุ getBar อาจเป็น idempotent, กำจัด () หรือทำลาย () หมายถึงไม่มีการโทรอื่นบนวัตถุเดียวกัน จะเป็นไปได้ ฯลฯ ... )