REST คืออะไร สับสนเล็กน้อย [ปิด]

ฉันอยู่ภายใต้การสันนิษฐานว่า REST เป็นบริการเว็บ แต่ดูเหมือนว่าฉันไม่ถูกต้องในการคิดสิ่งนี้ - ดังนั้น REST คืออะไร

ฉันอ่านวิกิพีเดียแล้ว แต่ก็ยังคลุมหัวไม่ได้อยู่ดี เหตุใดจึงต้องทำหลายที่อ้างถึง API เป็น REST API

REST ไม่ใช่บริการบนเว็บที่เฉพาะเจาะจง แต่เป็นแนวคิดการออกแบบ (สถาปัตยกรรม) สำหรับการจัดการข้อมูลสถานะ บทความเกี่ยวกับเรื่องนี้คือวิทยานิพนธ์ของ Roy Thomas Fielding (2000), "รูปแบบสถาปัตยกรรมและการออกแบบสถาปัตยกรรมซอฟต์แวร์ที่ใช้เครือข่าย" ( มีให้ทางออนไลน์จากมหาวิทยาลัยแคลิฟอร์เนียเออร์ไวน์)

อ่านโพสต์ของ Ryan Tomayko เป็นครั้งแรกฉันจะอธิบาย REST กับภรรยาของฉันอย่างไร มันเป็นจุดเริ่มต้นที่ดี จากนั้นอ่านวิทยานิพนธ์จริงของฟีลดิง มันไม่ได้สูงขนาดนั้นหรือไม่ยาว (หกบท 180 หน้า)! (ฉันรู้ว่าเด็ก ๆ ในโรงเรียนชอบสั้น)

แก้ไข: ฉันรู้สึกว่าไม่มีประโยชน์ที่จะพยายามอธิบาย REST มันมีแนวคิดมากมายเช่นความยืดหยุ่น, การมองเห็น (ไร้สัญชาติ) ฯลฯ ที่ผู้อ่านจำเป็นต้องเข้าใจและแหล่งข้อมูลที่ดีที่สุดสำหรับการทำความเข้าใจเหล่านั้นคือวิทยานิพนธ์จริง มันมากกว่า POST / GET เป็นต้น

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

วิธีคิดขั้นพื้นฐานที่สุดเกี่ยวกับ REST นั้นเป็นวิธีการจัดรูปแบบ URL ของเว็บแอปพลิเคชันของคุณ ตัวอย่างเช่นหากทรัพยากรของคุณถูกเรียกว่า "โพสต์" ดังนั้น:

/posts จะเป็นวิธีที่ผู้ใช้เข้าถึงโพสต์ทั้งหมดเพื่อแสดง

/posts/:id จะเป็นวิธีที่ผู้ใช้จะเข้าถึงและดูโพสต์แต่ละรายการที่ดึงมาตามรหัสเฉพาะของพวกเขา

/posts/new เป็นอย่างไรบ้างที่คุณจะแสดงฟอร์มสำหรับสร้างโพสต์ใหม่

การส่งคำขอ POST /usersจะเป็นวิธีที่คุณจะสร้างโพสต์ใหม่ในระดับฐานข้อมูล

การส่งคำขอ PUT /users/:idจะเป็นวิธีที่คุณจะอัปเดตแอตทริบิวต์ของโพสต์ที่ระบุอีกครั้งโดยใช้รหัสเฉพาะ

การส่งคำขอ DELETE /users/:idจะเป็นวิธีที่คุณจะลบโพสต์ที่ระบุอีกครั้งโดยใช้รหัสเฉพาะ

ตามที่ฉันเข้าใจแล้วรูปแบบ REST ได้รับความนิยมเป็นหลัก (สำหรับเว็บแอป) โดยกรอบ Ruby on Rails ซึ่งให้ความสำคัญกับเส้นทาง RESTful ฉันอาจจะผิดเกี่ยวกับที่แม้ว่า

ฉันอาจไม่ใช่ผู้ที่มีคุณสมบัติเหมาะสมที่สุดที่จะพูดคุยเกี่ยวกับเรื่องนี้ แต่นี่คือวิธีที่ฉันเรียนรู้ (โดยเฉพาะสำหรับการพัฒนา Rails)

เมื่อมีคนอ้างถึง "REST api" โดยทั่วไปสิ่งที่พวกเขาหมายถึงคือ API ที่ใช้ URL RESTful สำหรับการดึงข้อมูล

RESTเป็นรูปแบบสถาปัตยกรรมและการออกแบบสำหรับสถาปัตยกรรมซอฟต์แวร์ที่ใช้เครือข่าย

RESTแนวคิดจะเรียกว่าทรัพยากร การเป็นตัวแทนของทรัพยากรจะต้องไร้สัญชาติ มันถูกแสดงผ่านสื่อบางประเภท ตัวอย่างบางส่วนของสื่อประเภท ได้แก่XML, และJSON RDFทรัพยากรถูกควบคุมโดยส่วนประกอบ คอมโพเนนต์ร้องขอและจัดการทรัพยากรผ่านอินเทอร์เฟซแบบมาตรฐาน ในกรณีของ HTTP ที่อินเตอร์เฟซนี้ประกอบด้วย Ops HTTP มาตรฐานเช่นGET, PUT, ,POSTDELETE

RESTโดยทั่วไปมักใช้มากกว่าHTTPเนื่องจากความเรียบง่ายของ HTTP และการจับคู่ที่เป็นธรรมชาติกับหลักการ RESTful REST อย่างไรก็ตามไม่ได้เชื่อมโยงกับโปรโตคอลใด ๆ

หลักการ REST พื้นฐาน

การสื่อสารกับไคลเอนต์ - เซิร์ฟเวอร์

สถาปัตยกรรมไคลเอนต์ - เซิร์ฟเวอร์มีการแยกความกังวลอย่างชัดเจน แอ็พพลิเคชันทั้งหมดที่สร้างขึ้นในสไตล์ RESTful ต้องเป็นไคลเอ็นต์ - เซิร์ฟเวอร์ในหลักการ

ไร้สัญชาติ

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

แคชได้

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

ชุดอินเตอร์เฟส

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

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

ดูโพสต์บล็อกนี้ในหลักการออกแบบ RESTสำหรับรายละเอียดเพิ่มเติมเกี่ยวกับRESTและหลักการข้างต้น

มันย่อมาจาก Representational State Transfer และอาจมีความหมายหลายอย่าง แต่โดยทั่วไปเมื่อคุณพูดถึง API และแอปพลิเคชันคุณกำลังพูดถึง REST เป็นวิธีการบริการเว็บหรือรับโปรแกรมเพื่อพูดคุยผ่านเว็บ

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

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

คุ้มค่าในการอ่าน:

• ฉันอธิบายได้อย่างไรถึง REST to My Wife (ตอนนี้มีให้ที่นี่)
• ลักษณะสถาปัตยกรรมและการออกแบบสถาปัตยกรรมซอฟต์แวร์ที่ใช้เครือข่าย

http://en.wikipedia.org/wiki/Representational_State_Transfer

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