ความแตกต่างระหว่าง REST และ CRUD

ฉันเรียนรู้ REST และรู้สึกเหมือน CRUD (จากสิ่งที่ฉันอ่านเกี่ยวกับ CRUD)

ฉันรู้ว่าพวกเขาแตกต่างกันและฉันสงสัยว่าการคิดว่าพวกเขาเหมือนกันหมายความว่าฉันไม่เข้าใจพวกเขา

REST นั้นเป็น "superset" ของ CRUD หรือไม่? ทุกสิ่งที่ CRUD ทำและอื่น ๆ

น่าแปลกที่ฉันไม่เห็นคำตอบอื่น ๆ ในสิ่งที่ฉันพิจารณาถึงความแตกต่างที่แท้จริงระหว่าง REST และ CRUD: สิ่งที่แต่ละคนจัดการ

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

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

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

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

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

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

คนแรกจัดการข้อมูลพื้นฐานอื่น ๆ โต้ตอบกับระบบที่ซับซ้อน

ประการแรกทั้งคู่เป็นชื่อย่อทั่วไป พวกเขาไม่กลัวอะไรเลย

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

REST อย่างไรก็ตามเป็นแบบฝึกหัดที่มีชื่อ (เช่นเดียวกับ AJAX) ไม่ใช่เทคโนโลยีในตัวเอง มันสนับสนุนการใช้ความสามารถที่มีมานานแล้วในโปรโตคอล HTTP แต่ไม่ค่อยได้ใช้

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

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

แต่แนวคิด "วิธีการ" นี้ไม่ได้ใช้บ่อยนัก

โดยปกติผู้คนมักจะลิงก์ไปยังหน้าต่างๆผ่านวิธีการ GET และออกการอัปเดตทุกประเภท (การลบการแทรกการปรับปรุง) ผ่านวิธีการ POST

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

http://...com/posts/create- POST request  -> Goes to posts.create() method in the server
http://...com/posts/1/show- GET request  -> Goes to posts.show(1) method in the server
http://...com/posts/1/delete - POST request  -> Goes to posts.delete(1) method in the server
http://...com/posts/1/edit- POST request  -> Goes to posts.edit(1) method in the server

ด้วย REST คุณสร้างฟอร์มที่ฉลาดขึ้นเพราะใช้วิธี HTTP อื่น ๆ นอกเหนือจาก POST และตั้งโปรแกรมเซิร์ฟเวอร์ของคุณเพื่อให้สามารถแยกแยะระหว่างวิธีต่างๆไม่ใช่ URLS เท่านั้น ตัวอย่างเช่น:

http://...com/posts - POST request  -> Goes to posts.create() method in the server
http://...com/posts/1 - GET request  -> Goes to posts.show(1) method in the server
http://...com/posts/1 - DELETE request  -> Goes to posts.delete(1) method in the server
http://...com/posts/1 - PUT request  -> Goes to posts.edit(1) method in the server

จำไว้ว่า URL เดียวอธิบายถึงทรัพยากรเดียว โพสต์เดียวเป็นทรัพยากรเดียว ด้วย REST คุณจะปฏิบัติต่อทรัพยากรในแบบที่ควรปฏิบัติ คุณกำลังบอกเซิร์ฟเวอร์ว่าคุณต้องการใช้ทรัพยากรใดและจัดการอย่างไร

มีคุณสมบัติอื่น ๆ อีกมากมายสำหรับ "สถาปัตยกรรมสงบ" ซึ่งคุณสามารถอ่านได้ใน Wikipedia บทความหรือหนังสืออื่น ๆ หากคุณสนใจ ในทางตรงกันข้าม CRUD นั้นมีจำนวนไม่มากนัก

REST ย่อมาจาก "Representational State Transfer" ซึ่งหมายถึงการติดต่อสื่อสารและแก้ไขสถานะของทรัพยากรบางอย่างในระบบ

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

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

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

อย่างไรก็ตาม HTTP ใช้สไตล์ "สร้างหรืออัปเดต" ในขณะที่ CRUD แยกการสร้างและอัปเดต ทำให้การทำแผนที่ทั่วไปที่สะอาดระหว่างสอง (!) นั้นเป็นไปไม่ได้ (!)

รับและลบเป็นเรื่องง่าย ... รับ === ผลตอบแทนและลบ ===

แต่ตามข้อมูลจำเพาะ HTTP PUT จะสร้างและอัปเดตตามจริง:

• ใช้ PUT เพื่อสร้างวัตถุใหม่เมื่อคุณรู้ทุกอย่างเกี่ยวกับมันรวมถึงตัวระบุ

• ใช้ PUT เพื่ออัปเดตวัตถุ (โดยปกติแล้วจะมีการนำเสนอวัตถุอย่างสมบูรณ์)

POST คือกริยา "กำลังประมวลผล" และถือเป็นกริยา "ผนวก":

• ใช้ POST เพื่อผนวกวัตถุใหม่เข้ากับคอลเล็กชันนั่นคือสร้างวัตถุใหม่

• POST ยังใช้เมื่อไม่มีกริยาอื่นที่ค่อนข้างเหมาะสมเนื่องจากข้อมูลจำเพาะ HTTP กำหนดว่าเป็นกริยา "การประมวลผลข้อมูล"

• หากทีมของคุณกำลังวางสาย POST โปรดจำไว้ว่า WWW ทั้งหมดถูกสร้างขึ้นบน GET และ POST;)

ดังนั้นในขณะที่มีความคล้ายคลึงกันระหว่าง REST และ CRUD ความผิดพลาดที่ฉันเห็นทีมส่วนใหญ่ทำคือการทำให้เท่าเทียมกันระหว่างสอง ทีมต้องระวังอย่างยิ่งเมื่อกำหนด REST API เพื่อไม่ให้วางสายใน CRN ช่วยจำเนื่องจาก REST เป็นวิธีปฏิบัติมีความซับซ้อนเพิ่มขึ้นมากมายที่ไม่ได้จับคู่กับ CRUD อย่างหมดจด

CRUD ระบุคำกริยาการจัดเก็บพื้นฐานขั้นต่ำสำหรับการอ่านและการเขียนข้อมูล: สร้างอ่านอัปเดตและลบ จากนั้นคุณสามารถสร้างการดำเนินการอื่น ๆ โดยรวมสิ่งเหล่านี้ สิ่งเหล่านี้มักจะถือว่าเป็นการดำเนินงานฐานข้อมูล แต่สิ่งที่ถือว่าเป็นฐานข้อมูลโดยพลการ (เช่นอาจเป็น DBMS เชิงสัมพันธ์ แต่อาจเป็นไฟล์ YAML)

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

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

CRUD

• CRUD เป็นคำสั่ง SQL พื้นฐานสี่ประเภท: สร้างอ่านอัปเดตและลบ
• แอปพลิเคชั่นส่วนใหญ่มีฟังก์ชั่น CRUD บางประเภท
• แอปพลิเคชัน CRUD เป็นแอปที่ใช้แบบฟอร์มเพื่อรับข้อมูลเข้าและออกจากฐานข้อมูล

ส่วนที่เหลือ

• REST ย่อมาจาก Representational State Transfer (บางครั้งมันสะกดว่า "ReST")

• มันขึ้นอยู่กับไร้รัฐลูกค้า - เซิร์ฟเวอร์โปรโตคอลการสื่อสารที่แคชและในเกือบทุกกรณีโปรโตคอล HTTP จะใช้

• REST เป็นรูปแบบสถาปัตยกรรมสำหรับการออกแบบแอพพลิเคชั่นเครือข่าย

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

ฉันคิดว่า REST ที่สับสนกับ CRUD นั้นเป็นข้อผิดพลาดทั่วไปและสาเหตุก็คือผู้พัฒนาไม่มีเวลาอ่านเกี่ยวกับ REST ในเชิงลึก พวกเขาต้องการใช้เทคโนโลยี - โดยไม่เข้าใจ - ตามตัวอย่างสไตล์ CRUD ที่ จำกัด ซึ่งเขียนโดยนักพัฒนาที่คล้ายกัน ตัวอย่างและแบบฝึกหัดส่วนใหญ่สะท้อนให้เห็นถึงการขาดความรู้อย่างจริงจัง การแม็พ REST กับเอนทิตีและเมธอด HTTP เพื่อการดำเนินการ CRUD ของเอนทิตีเหล่านี้และการใช้ REST โดยไม่มีไฮเปอร์ลิงก์เป็นเพียงอาการของสิ่งนั้น โดย REST คุณแมปการเชื่อมโยงหลายมิติ (รวมถึงการเชื่อมโยงด้วยวิธี POST / PUT / DELETE / PATCH) กับการดำเนินงานของคุณและคุณระบุการดำเนินการในฝั่งไคลเอ็นต์โดยการตรวจสอบการเชื่อมโยง (ปกติ API เฉพาะ) API หากไคลเอนต์ REST ไม่ทราบว่าการเชื่อมโยงคืออะไรและรู้เพียงวิธีการ HTTP และเทมเพลต URI บางอัน นั่นไม่ใช่ไคลเอ็นต์ REST แต่เป็น CRUD บนไคลเอ็นต์ HTTP ข้อผิดพลาดทั่วไปอื่น ๆ ที่ไคลเอนต์ REST เป็นแอปพลิเคชันจาวาสคริปต์หน้าเดียวที่ทำงานในเบราว์เซอร์ แน่นอนว่าคุณสามารถใช้ไคลเอ็นต์ดังกล่าวได้ แต่ส่วนที่เหลือนั้นมีความหมายเป็นหลักสำหรับไคลเอ็นต์อัตโนมัติ (แอปพลิเคชันฝั่งเซิร์ฟเวอร์ที่เขียนโดยนักพัฒนาที่คุณไม่รู้จัก) และไม่ใช้สำหรับไคลเอ็นต์ด้วยตนเอง การมีไคลเอ็นต์เบราว์เซอร์เพียงตัวเดียวอาจเป็นสัญญาณว่าคุณไม่จำเป็นต้องใช้ REST จริง ๆ และคุณเพิ่งจะล้มเลิกโครงการไป ในกรณีเหล่านี้ CRUD API เป็นโซลูชันที่ทำงานได้และนักพัฒนาเรียก API CRUD เหล่านี้เป็น REST เนื่องจากไม่ทราบความแตกต่าง แน่นอนว่าคุณสามารถใช้ไคลเอ็นต์ดังกล่าวได้ แต่ส่วนที่เหลือนั้นมีความหมายเป็นหลักสำหรับไคลเอ็นต์อัตโนมัติ (แอปพลิเคชันฝั่งเซิร์ฟเวอร์ที่เขียนโดยนักพัฒนาที่คุณไม่รู้จัก) และไม่ใช้สำหรับไคลเอ็นต์ด้วยตนเอง การมีไคลเอ็นต์เบราว์เซอร์เพียงตัวเดียวอาจเป็นสัญญาณว่าคุณไม่จำเป็นต้องใช้ REST จริง ๆ และคุณเพิ่งจะล้มเลิกโครงการไป ในกรณีเหล่านี้ CRUD API เป็นโซลูชันที่ทำงานได้และนักพัฒนาเรียก API CRUD เหล่านี้เป็น REST เนื่องจากไม่ทราบความแตกต่าง แน่นอนว่าคุณสามารถใช้ไคลเอ็นต์ดังกล่าวได้ แต่ส่วนที่เหลือนั้นมีความหมายเป็นหลักสำหรับไคลเอ็นต์อัตโนมัติ (แอปพลิเคชันฝั่งเซิร์ฟเวอร์ที่เขียนโดยนักพัฒนาที่คุณไม่รู้จัก) และไม่ใช้สำหรับไคลเอ็นต์ด้วยตนเอง การมีไคลเอ็นต์เบราว์เซอร์เพียงตัวเดียวอาจเป็นสัญญาณว่าคุณไม่จำเป็นต้องใช้ REST จริง ๆ และคุณเพิ่งจะล้มเลิกโครงการไป ในกรณีเหล่านี้ CRUD API เป็นโซลูชันที่ทำงานได้และนักพัฒนาเรียก API CRUD เหล่านี้เป็น REST เนื่องจากไม่ทราบความแตกต่าง