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

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

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

ไคลเอนต์ - เวิร์กสเตชันสำหรับผู้ใช้หนึ่งรายซึ่งมีโหมดการลงทะเบียนและฟังก์ชั่นอื่น ๆ ที่จำเป็นในที่ทำงานของเขา - การคำนวณ, การสื่อสาร, การเข้าถึงฐานข้อมูล ฯลฯ ไคลเอนต์สามารถเรียกได้ว่าเป็นโปรแกรมที่ใช้บริการที่ได้รับจากโปรแกรมเซิร์ฟเวอร์ ตัวอย่างไคลเอนต์ - MSIE (MS Internet Explorer), ไคลเอนต์ ICQ

บ่อยครั้งที่ผู้คนอ้างถึงคอมพิวเตอร์ที่หนึ่งในโปรแกรมเหล่านี้ทำงานเป็นไคลเอนต์หรือเซิร์ฟเวอร์

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

หากเราทำการเปรียบเทียบกับสังคม - ธนาคารหรือร้านค้า - "เซิร์ฟเวอร์" พวกเขาให้บริการบางอย่างแก่ลูกค้าของตน แต่ธนาคารอาจเป็นลูกค้าของบริษัทอื่นในเวลาเดียวกัน ฯลฯ...

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

DBMS จากคอมพิวเตอร์ส่วนบุคคล (เช่น Clipper, DBase, FoxPro, Paradox, Clarion มีเวอร์ชันเครือข่ายที่แชร์ไฟล์ฐานข้อมูลในรูปแบบเดียวกันสำหรับพีซี ในขณะที่ใช้การล็อคเครือข่ายเพื่อจำกัดการเข้าถึงตารางและบันทึก อย่างไรก็ตาม งานทั้งหมดจะดำเนินการ บนพีซี เซิร์ฟเวอร์ถูกใช้เป็นดิสก์ระยะไกลที่ใช้ร่วมกันซึ่งมีความจุสูง วิธีดำเนินการนี้นำไปสู่ความเสี่ยงที่ข้อมูลจะสูญหายเนื่องจากความล้มเหลวของฮาร์ดแวร์

เมื่อเปรียบเทียบกับระบบดังกล่าว ระบบที่สร้างขึ้นในสถาปัตยกรรมไคลเอนต์-เซิร์ฟเวอร์มีข้อดีดังต่อไปนี้:

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


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


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


ลดปริมาณข้อมูลที่ส่งผ่านเครือข่ายหลายครั้ง


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


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


1.2. เรื่องราว…


สถาปัตยกรรมและคำว่า "ไคลเอนต์-เซิร์ฟเวอร์" ถูกใช้ครั้งแรกในช่วงต้นทศวรรษที่ 80 แอปพลิเคชันแรกที่มีสถาปัตยกรรมไคลเอ็นต์-เซิร์ฟเวอร์คือฐานข้อมูล


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


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


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


1.3. โปรโตคอล


เซิร์ฟเวอร์และไคลเอนต์บนเครือข่าย "พูดคุย" กันใน "ภาษา" (ในความหมายกว้าง ๆ ของคำ) ที่ทั้งสองฝ่ายเข้าใจได้ “ภาษา” นี้เรียกว่าโปรโตคอล


ในกรณีของธนาคาร โปรโตคอลสามารถเรียกว่าแบบฟอร์มที่ลูกค้ากรอก


ในกรณีของเรา ตัวอย่างของโปรโตคอล:


FTP (โปรโตคอลการถ่ายโอนไฟล์)


HTTP (โปรโตคอลการถ่ายโอนข้อความแบบไฮเปอร์)


SMTP (โปรโตคอลการโอนจดหมายอย่างง่าย)


IP (อินเทอร์เน็ตโปรโตคอล)


โปรโตคอลไคลเอ็นต์/เซิร์ฟเวอร์ MySQL


โปรดทราบว่าโปรโตคอลสามารถมีได้ในระดับที่แตกต่างกัน ระบบการจำแนกระดับอาจแตกต่างกัน แต่หนึ่งในบรรทัดที่มีชื่อเสียงที่สุดคือ OSI (Open Systems Interconnection) ซึ่งมี 7 ระดับ


ตัวอย่างเช่น HTTP เป็นโปรโตคอลเลเยอร์แอปพลิเคชัน (สูงสุดที่เจ็ด) และ IP เป็นโปรโตคอลเครือข่าย (ที่สาม)


1.4. การกระจายฟังก์ชันในสถาปัตยกรรมไคลเอ็นต์-เซิร์ฟเวอร์


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


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


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


หน้าที่หลักของเซิร์ฟเวอร์ DBMS คือการรับประกันความน่าเชื่อถือ ความสม่ำเสมอ และความปลอดภัยของข้อมูล การจัดการคำขอของลูกค้า และการประมวลผลคำสั่ง SQL ที่รวดเร็ว


ตรรกะทั้งหมดของแอปพลิเคชัน - งานแอปพลิเคชัน, กฎเกณฑ์ทางธุรกิจ - ในสถาปัตยกรรมสองชั้นนั้นแจกจ่ายโดยนักพัฒนาระหว่างสองกระบวนการ: ไคลเอนต์และเซิร์ฟเวอร์ (รูปที่ 1)


ในตอนแรก ฟังก์ชั่นส่วนใหญ่ของแอปพลิเคชันได้รับการแก้ไขโดยไคลเอนต์ เซิร์ฟเวอร์เกี่ยวข้องกับการประมวลผลคำสั่ง SQL เท่านั้น สถาปัตยกรรมนี้เรียกว่า "เซิร์ฟเวอร์แบบหนา - เซิร์ฟเวอร์แบบบาง"


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


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


รุ่นที่กล่าวถึงข้างต้นมีข้อเสียดังต่อไปนี้


1. ลูกค้า “หนา”:


– ความซับซ้อนของการบริหาร


– การอัปเดตซอฟต์แวร์มีความซับซ้อนมากขึ้น เนื่องจากจะต้องเปลี่ยนพร้อมกันทั่วทั้งระบบ


– การกระจายอำนาจมีความซับซ้อนมากขึ้น เนื่องจากการเข้าถึงไม่ได้ถูกจำกัดด้วยการกระทำ แต่ด้วยตาราง


– เครือข่ายโอเวอร์โหลดเนื่องจากการส่งข้อมูลที่ยังไม่ได้ประมวลผลผ่านเครือข่ายนั้น


– การป้องกันข้อมูลที่อ่อนแอ เนื่องจากเป็นการยากที่จะกระจายอำนาจอย่างถูกต้อง


2. เซิร์ฟเวอร์ “อ้วน”:


– การใช้งานมีความซับซ้อนมากขึ้น เนื่องจากภาษาอย่าง PL/SQL ไม่เหมาะสำหรับการพัฒนาซอฟต์แวร์ดังกล่าว และไม่มีเครื่องมือแก้ไขข้อบกพร่องที่ดี


– ประสิทธิภาพของโปรแกรมที่เขียนด้วยภาษาเช่น PL/SQL นั้นต่ำกว่าโปรแกรมที่สร้างในภาษาอื่นอย่างมาก ซึ่งมีความสำคัญสำหรับระบบที่ซับซ้อน


– โปรแกรมที่เขียนด้วยภาษา DBMS มักจะทำงานไม่น่าเชื่อถือ ข้อผิดพลาดอาจทำให้เซิร์ฟเวอร์ฐานข้อมูลทั้งหมดล้มเหลว


– โปรแกรมผลลัพธ์ไม่สามารถพกพาไปยังระบบและแพลตฟอร์มอื่นได้อย่างสมบูรณ์


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


อย่างไรก็ตาม ภาษาที่ใช้เขียน Stored Procedure นั้นไม่มีประสิทธิภาพหรือยืดหยุ่นพอที่จะปรับใช้ตรรกะของแอปพลิเคชันที่ซับซ้อนได้อย่างง่ายดาย


จากนั้นมีแนวโน้มที่จะมอบความไว้วางใจในการปฏิบัติงานแอปพลิเคชันและกฎเกณฑ์ทางธุรกิจให้กับส่วนประกอบแอปพลิเคชันที่แยกจากกัน (หรือส่วนประกอบหลายส่วน) ซึ่งสามารถทำงานบนคอมพิวเตอร์เฉพาะพิเศษ - แอปพลิเคชันเซิร์ฟเวอร์หรือบนคอมพิวเตอร์เครื่องเดียวกับที่เซิร์ฟเวอร์ฐานข้อมูลทำงาน . นี่คือวิธีที่สถาปัตยกรรมไคลเอนต์-เซิร์ฟเวอร์สามระดับและหลายระดับเกิดขึ้น





ข้าว. 1. การกระจายฟังก์ชันระหว่างไคลเอนต์และเซิร์ฟเวอร์


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



รายการอ้างอิงที่ใช้

1. สารสนเทศ / เอ็ด เอ็น.วี. มาคาโรวา – ม.: การเงินและสถิติ, 2541.
   

   เอฟโดคิมอฟ วี.วี. และอื่นๆ สารสนเทศทางเศรษฐกิจ เซนต์ปีเตอร์สเบิร์ก: ปีเตอร์ 2547
   

   คาซาคอฟ เอส.ไอ. พื้นฐานของเทคโนโลยีเครือข่าย - อ.: วิทยุและการสื่อสาร, 2547
   

   Kogalovsky M.R. เทคโนโลยีฐานข้อมูลบนคอมพิวเตอร์ส่วนบุคคล - M.: การเงินและสถิติ, 2546
   

   โปปอฟ วี.วี. พื้นฐานของเทคโนโลยีคอมพิวเตอร์ –ม.: การเงินและสถิติ, 2544.
   

   ฟิกูร์นอฟ วี.อี. IBM PC สำหรับผู้ใช้ ม., 2000.
   

ระบบปฏิบัติการ MS-DOS แนวคิดพื้นฐานและคำสั่ง แนวคิดพื้นฐาน: ฐานข้อมูล, DBMS, เอนทิตี, คุณลักษณะ, ความสัมพันธ์ (หนึ่งต่อหนึ่ง, หนึ่งต่อหลาย, หลายต่อหลาย) ความสัมพันธ์, คีย์หลัก

สถาปัตยกรรมไฟล์เซิร์ฟเวอร์

สถาปัตยกรรมระบบสารสนเทศแบบดั้งเดิม

หน้าที่พื้นฐานของระบบสารสนเทศ

สถาปัตยกรรมระบบสารสนเทศ- แนวคิดที่กำหนดแบบจำลอง โครงสร้าง ฟังก์ชันที่ดำเนินการ และการเชื่อมโยงระหว่างส่วนประกอบต่างๆ ของระบบสารสนเทศ (อภิธานศัพท์)

จากมุมมอง การใช้ซอฟต์แวร์และฮาร์ดแวร์สามารถระบุสถาปัตยกรรม IC ทั่วไปได้จำนวนหนึ่ง

ส่วนประกอบของระบบข้อมูลสามารถแบ่งออกเป็นสามชั้นตามฟังก์ชันการทำงาน: ชั้นการนำเสนอ ชั้นตรรกะทางธุรกิจ และชั้นการเข้าถึงข้อมูล

เลเยอร์การนำเสนอ- ทุกอย่างที่เกี่ยวข้องกับการโต้ตอบกับผู้ใช้: การกดปุ่ม การเลื่อนเมาส์ การวาดภาพ การแสดงผลการค้นหา ฯลฯ

ตรรกะทางธุรกิจ- กฎ, อัลกอริธึมสำหรับการตอบสนองของแอปพลิเคชันต่อการกระทำของผู้ใช้หรือเหตุการณ์ภายใน, กฎการประมวลผลข้อมูล

ชั้นการเข้าถึงข้อมูล- การจัดเก็บ การเรียกค้น การแก้ไข และการลบข้อมูลที่เกี่ยวข้องกับงานแอปพลิเคชันที่กำลังแก้ไขโดยแอปพลิเคชัน

เครือข่ายท้องถิ่นปรากฏขึ้น ไฟล์เริ่มถูกถ่ายโอนผ่านเครือข่าย ในตอนแรกมีเครือข่ายแบบเพียร์ทูเพียร์ - คอมพิวเตอร์ทุกเครื่องมีสิทธิ์เท่าเทียมกัน 3

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

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

จำนวนลูกค้าถูกจำกัดไว้ที่สิบคน

1. โหมดผู้ใช้หลายคนสำหรับการทำงานกับข้อมูล

2. ความสะดวกในการควบคุมการเข้าถึงจากส่วนกลาง

3. ต้นทุนการพัฒนาต่ำ

1. ประสิทธิภาพต่ำ

2. ความน่าเชื่อถือต่ำ

3. ความสามารถในการขยายที่อ่อนแอ

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

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

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

คุณสมบัติหลัก: 5

 โปรแกรมไคลเอนต์ทำงานกับข้อมูลผ่านการร้องขอไปยังซอฟต์แวร์เซิร์ฟเวอร์

 ฟังก์ชันพื้นฐานของแอปพลิเคชันจะถูกแบ่งระหว่างไคลเอนต์และเซิร์ฟเวอร์

 รองรับการทำงานแบบหลายผู้ใช้อย่างเต็มที่

 การรับประกันความสมบูรณ์ของข้อมูล

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

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

 การป้องกันข้อมูลที่อ่อนแอจากการแฮ็ก โดยเฉพาะจากผู้ใช้ระบบที่ไร้ยางอาย

 ความซับซ้อนสูงในการดูแลระบบและการกำหนดค่าเวิร์กสเตชันผู้ใช้ของระบบ

 ความจำเป็นในการใช้พีซีที่มีประสิทธิภาพที่ไซต์ไคลเอนต์

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

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

เปลี่ยนผ่านเป็นสถาปัตยกรรมสามชั้น (2.5 ชั้น)

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

อย่างที่คุณเห็น การจัดระเบียบของระบบนี้ชวนให้นึกถึงการจัดระเบียบของระบบรวมแรกอย่างมาก โดยมีข้อแตกต่างเพียงอย่างเดียวว่าสถานที่ของผู้ใช้ไม่ใช่เทอร์มินัล (ที่มีหน้าจอสีเขียวฉาวโฉ่) แต่เป็นคอมพิวเตอร์ส่วนบุคคลที่มี GUI ตัวอย่างเช่นเมื่อเร็ว ๆ นี้เนื่องจากโปรแกรมไคลเอนต์มักใช้เบราว์เซอร์ www มาตรฐาน แน่นอนว่าการกลับคืนสู่ระบบที่เกือบจะรวมกันนั้นเกิดขึ้นในระดับเทคโนโลยีที่แตกต่างกัน การใช้ DBMS พร้อมข้อดีทั้งหมดกลายเป็นสิ่งจำเป็น โปรแกรมสำหรับฝั่งเซิร์ฟเวอร์เขียนเป็นภาษาเฉพาะเป็นหลัก โดยใช้กลไกของกระบวนการจัดเก็บของเซิร์ฟเวอร์ฐานข้อมูล อย่างไรก็ตาม ในระดับองค์กรเชิงตรรกะ IS ในสถาปัตยกรรมไคลเอ็นต์-เซิร์ฟเวอร์ที่มีธินไคลเอ็นต์จะถูกแบ่งออกเป็นสามชั้น ได้แก่ ชั้นข้อมูล ชั้นฟังก์ชันทางธุรกิจ (ขั้นตอนการจัดเก็บ) และชั้นการนำเสนอ น่าเสียดายที่โดยปกติแล้วในรูปแบบการออกแบบ IS นั้นเป็นไปไม่ได้ที่จะเขียนตรรกะทางธุรกิจทั้งหมดของแอปพลิเคชันในภาษา DBMS ในตัวที่ไม่ได้มีไว้สำหรับจุดประสงค์นี้ ด้วยเหตุนี้ บ่อยครั้งที่ฟังก์ชันทางธุรกิจส่วนหนึ่งถูกนำไปใช้ในส่วนของระบบของลูกค้า ซึ่งส่งผลให้ "อ้วนขึ้น" อย่างหลีกเลี่ยงไม่ได้ ส่วนหนึ่งเป็นเพราะสิ่งนี้ และส่วนหนึ่งเป็นเพราะไอซีดังกล่าวทางกายภาพประกอบด้วยสององค์ประกอบ สถาปัตยกรรมนี้จึงมักเรียกว่าสถาปัตยกรรมไคลเอนต์-เซิร์ฟเวอร์ 2.5 เลเยอร์

ต่างจากสถาปัตยกรรม 2 เลเยอร์ สถาปัตยกรรม 2.5 เลเยอร์มักจะไม่ต้องการช่องทางการสื่อสารความเร็วสูงระหว่างไคลเอนต์และเซิร์ฟเวอร์ส่วนของระบบ เนื่องจากผลการคำนวณสำเร็จรูปจะถูกส่งผ่านเครือข่าย - การคำนวณเกือบทั้งหมดจะดำเนินการบนฝั่งเซิร์ฟเวอร์ . การปกป้องข้อมูลได้รับการปรับปรุงอย่างมีนัยสำคัญเช่นกัน - ผู้ใช้จะได้รับสิทธิ์ในการเข้าถึงฟังก์ชั่นของระบบและไม่สามารถเข้าถึงข้อมูลได้ ฯลฯ ในเวลาเดียวกัน พร้อมด้วยข้อดีของแนวทางแบบรวม สถาปัตยกรรม 2.5 ยังนำข้อเสียทั้งหมดมาใช้ เช่น ความสามารถในการขยายที่จำกัด การพึ่งพาแพลตฟอร์มซอฟต์แวร์ การใช้ทรัพยากรคอมพิวเตอร์เครือข่ายอย่างจำกัด นอกจากนี้ โปรแกรมสำหรับส่วนเซิร์ฟเวอร์ของระบบยังเขียนด้วยภาษาขั้นตอนการจัดเก็บที่สร้างไว้ใน DBMS ซึ่งมีไว้สำหรับการตรวจสอบข้อมูลและสร้างรายงานอย่างง่าย ไม่ใช่สำหรับการเขียน IS ระดับองค์กรเลย ทั้งหมดนี้ช่วยลดความเร็วของระบบ เพิ่มความซับซ้อนในการสร้างและแก้ไข IC และมีผลกระทบด้านลบมากที่สุดต่อต้นทุนของฮาร์ดแวร์ที่จำเป็นสำหรับการดำเนินงาน

Vladimir นักพัฒนาเว็บของ Noveo กล่าวว่า:

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

ประมาณที่หนึ่ง: ตัวละคร

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

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

ไคลเอนต์และเซิร์ฟเวอร์

เซิร์ฟเวอร์ในกรณีนี้ เราจะพิจารณาเครื่องที่เป็นนามธรรมบนเครือข่ายที่สามารถรับคำขอ HTTP ประมวลผลและส่งกลับการตอบสนองที่ถูกต้อง ในบริบทของบทความนี้ สาระสำคัญทางกายภาพและสถาปัตยกรรมภายในนั้นไม่สำคัญเลย ไม่ว่าจะเป็นแล็ปท็อปสำหรับนักเรียนหรือเซิร์ฟเวอร์อุตสาหกรรมขนาดใหญ่ที่กระจายอยู่ทั่วโลก ในทำนองเดียวกัน มันไม่สำคัญสำหรับเราว่ามีอะไรซ่อนอยู่ ใครทักทายคำขอที่ประตู Apache หรือ Nginx สัตว์ร้ายที่ไม่รู้จัก PHP Python หรือ Ruby ประมวลผลและสร้างการตอบสนอง ใช้ที่จัดเก็บข้อมูลใด : PostgreSQL, MySQL หรือ MongoDB สิ่งสำคัญคือเซิร์ฟเวอร์ตรงตามกฎหลัก - ที่จะได้ยิน เข้าใจ และให้อภัย

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

โดยส่วนใหญ่เราจะพูดถึงวิธีการสื่อสารระหว่างคนทั้งสองข้างต้นในลักษณะที่พวกเขาเข้าใจกันและทั้งสองคนก็ไม่มีคำถามใดๆ

ปรัชญาการพักผ่อน

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

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

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

ตัวอย่าง:รับ /api/v1/users/25/name.get

ความเป็นอิสระของรูปแบบการจัดเก็บข้อมูลจากรูปแบบการส่งข้อมูล- เซิร์ฟเวอร์สามารถรองรับรูปแบบที่แตกต่างกันหลายรูปแบบสำหรับการส่งข้อมูลเดียวกัน (JSON, XML ฯลฯ ) แต่จัดเก็บข้อมูลในรูปแบบภายใน ไม่ว่าจะรองรับรูปแบบใดก็ตาม

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

เราขาดอะไรไป?

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

การเรียกใช้ฟังก์ชัน

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

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

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

และยังมีการดำเนินการที่ไม่เกี่ยวข้องโดยตรงกับการจัดเก็บข้อมูล เช่น การส่งการแจ้งเตือน การยืนยันหรือปฏิเสธการดำเนินการใดๆ (การสิ้นสุดระยะเวลาการรายงาน เป็นต้น)

การดำเนินงานหลายอย่าง

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

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

การสืบค้นทางสถิติ ผู้รวบรวมข้อมูล การจัดรูปแบบข้อมูล

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

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

ประเภทของข้อมูล

วัตถุ

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

คอลเลกชันของวัตถุ

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

ค่าสเกลาร์

ในรูปแบบที่บริสุทธิ์ ค่าสเกลาร์ในฐานะเอนทิตีที่แยกจากกันนั้นหายากมากในความทรงจำของฉัน โดยปกติแล้วสิ่งเหล่านี้จะปรากฏเป็นคุณสมบัติของวัตถุหรือคอลเลกชัน และสามารถอ่านหรือเขียนได้ ตัวอย่างเช่น ชื่อผู้ใช้สามารถดึงข้อมูลและเปลี่ยนแปลงทีละรายการได้ด้วย GET /users/1/name ในทางปฏิบัติ คุณลักษณะนี้ไม่ค่อยมีประโยชน์ แต่ถ้าจำเป็น ฉันอยากให้มีไว้ใช้ โดยเฉพาะอย่างยิ่งสำหรับคุณสมบัติคอลเลกชัน เช่น จำนวนบันทึก (มีหรือไม่มีการกรอง): GET /news/count

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

ประมาณที่สอง: เส้นทางที่ถูกต้อง

ในแนวทางนี้ ฉันอยากจะพูดแยกกันเกี่ยวกับแนวทางในการสร้างเส้นทางเฉพาะไปยังทรัพยากรและวิธีการของ API เว็บของคุณ และเกี่ยวกับคุณลักษณะทางสถาปัตยกรรมของแอปพลิเคชันที่ส่งผลต่อลักษณะที่ปรากฏของเส้นทางนี้และส่วนประกอบต่างๆ

สิ่งที่ควรคำนึงถึงขณะยืนอยู่บนฝั่ง

การกำหนดเวอร์ชัน

ไม่ช้าก็เร็วระบบปฏิบัติการใดๆ ก็เริ่มมีการพัฒนา: พัฒนา, ซับซ้อนมากขึ้น, ปรับขนาดได้ และทันสมัยมากขึ้น สำหรับนักพัฒนา REST API สิ่งนี้เต็มไปด้วยความจำเป็นในการเปิดตัว API เวอร์ชันใหม่ในขณะที่เวอร์ชันเก่ากำลังทำงานอยู่ ในที่นี้ฉันไม่ได้พูดถึงการเปลี่ยนแปลงทางสถาปัตยกรรมภายใต้ประทุนของระบบของคุณอีกต่อไป แต่เกี่ยวกับความจริงที่ว่ารูปแบบข้อมูลนั้นเองและชุดการดำเนินการที่มีการเปลี่ยนแปลง ไม่ว่าในกรณีใด จะต้องระบุเวอร์ชันสำหรับทั้งในการจัดระเบียบเริ่มต้นของซอร์สโค้ดและในหลักการของการสร้าง URL เมื่อพูดถึง URL มีสองวิธีที่ได้รับความนิยมมากที่สุดในการระบุเวอร์ชันของ API ที่จะจัดการกับคำขอ นำหน้าเส้นทาง example-api.com/v1/ และแยกเวอร์ชันที่ระดับโดเมนย่อย v1.example-api.com คุณสามารถใช้สิ่งเหล่านี้ได้ขึ้นอยู่กับความต้องการและความต้องการของคุณ

ความเป็นอิสระของส่วนประกอบ

Web API ของระบบที่ซับซ้อนที่รองรับบทบาทของผู้ใช้หลายบทบาทมักต้องมีการแบ่งออกเป็นส่วนๆ ซึ่งแต่ละส่วนจะทำหน้าที่ต่างๆ ของตัวเอง ในความเป็นจริง แต่ละส่วนสามารถเป็นแอปพลิเคชันอิสระที่ทำงานบนเครื่องและแพลตฟอร์มจริงที่แตกต่างกัน ในบริบทของการอธิบาย API นั้น ไม่ได้มีความสำคัญเลยสำหรับเราว่าเซิร์ฟเวอร์จะประมวลผลคำขออย่างไร และกองกำลังและเทคโนโลยีใดบ้างที่เกี่ยวข้องกับเรื่องนี้ สำหรับไคลเอนต์ API เป็นระบบแบบห่อหุ้ม อย่างไรก็ตาม ส่วนต่างๆ ของระบบอาจมีฟังก์ชันการทำงานที่แตกต่างกันโดยสิ้นเชิง เช่น ส่วนผู้ดูแลระบบและผู้ใช้ และวิธีการทำงานกับทรัพยากรที่ดูเหมือนจะเหมือนกันอาจแตกต่างกันอย่างมาก ดังนั้น ส่วนดังกล่าวจะต้องถูกแยกออกจากกันที่ระดับโดเมน admin.v1.example-api.com หรือคำนำหน้าเส้นทาง example-api.com/v1/admin/ ข้อกำหนดนี้ไม่บังคับ และส่วนใหญ่ขึ้นอยู่กับความซับซ้อนของระบบและวัตถุประสงค์ของระบบ

รูปแบบการแลกเปลี่ยนข้อมูล

ในความคิดของฉัน รูปแบบการแลกเปลี่ยนข้อมูลที่สะดวกและใช้งานได้มากที่สุดคือ JSON แต่ไม่มีใครห้ามการใช้ XML, YAML หรือรูปแบบอื่นใดที่ช่วยให้คุณจัดเก็บวัตถุที่ต่อเนื่องกันโดยไม่สูญเสียประเภทข้อมูล หากต้องการ คุณสามารถทำให้ API รองรับรูปแบบอินพุต/เอาต์พุตหลายรูปแบบได้ การใช้ส่วนหัวคำขอ HTTP เพื่อระบุรูปแบบการตอบสนองยอมรับที่ต้องการและประเภทเนื้อหาเพื่อระบุรูปแบบของข้อมูลที่ส่งในคำขอก็เพียงพอแล้ว อีกวิธีหนึ่งที่ได้รับความนิยมคือการเพิ่มส่วนขยายให้กับ URL ของทรัพยากร เช่น GET /users.xml แต่วิธีนี้ดูยืดหยุ่นและสวยงามน้อยลง หากเพียงเพราะมันทำให้ URL หนักขึ้นและเป็นจริงสำหรับคำขอ GET มากกว่าที่จะเป็นไปได้ทั้งหมด การดำเนินงาน

รองรับหลายภาษาและหลายภาษา

ในทางปฏิบัติ API หลายภาษาส่วนใหญ่มักเกี่ยวข้องกับการแปลบริการและข้อความแสดงข้อผิดพลาดเป็นภาษาที่จำเป็นสำหรับการแสดงผลโดยตรงต่อผู้ใช้ปลายทาง เนื้อหาหลายภาษาก็มีที่มาเช่นกัน แต่ในความคิดของฉัน การบันทึกและการออกเนื้อหาในภาษาต่าง ๆ ควรแยกความแตกต่างให้ชัดเจนยิ่งขึ้น ตัวอย่างเช่น หากคุณมีบทความเดียวกันในภาษาต่าง ๆ ที่จริงแล้วสิ่งเหล่านี้เป็นสองเอนทิตีที่แตกต่างกันซึ่งจัดกลุ่มตาม สัญลักษณ์ของความสามัคคีของเนื้อหา สามารถใช้วิธีการต่างๆ เพื่อระบุภาษาที่ต้องการได้ วิธีที่ง่ายที่สุดคือ Accept-Language ส่วนหัว HTTP มาตรฐาน ฉันเคยเห็นวิธีอื่นๆ เช่นการเพิ่มพารามิเตอร์ GET language="en" โดยใช้คำนำหน้าเส้นทาง example-api.com/en/ หรือแม้แต่ที่ระดับชื่อโดเมน en.example-api.com สำหรับฉันดูเหมือนว่าการเลือกวิธีระบุสถานที่นั้นขึ้นอยู่กับแอปพลิเคชันเฉพาะและงานที่เผชิญอยู่

เส้นทางภายใน

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

เส้นทางการสะสม

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

องค์ประกอบการสะสม

ในการเข้าถึงองค์ประกอบคอลเลกชันเฉพาะ เราจะใช้ตัวระบุเฉพาะ /users/25 ในเส้นทาง นี่คือเส้นทางที่ไม่เหมือนใคร ในการทำงานกับวัตถุ จะใช้วิธี GET (การรับวัตถุ), PUT/PATCH (การเปลี่ยนแปลง) และ DELETE (การลบ)

วัตถุที่ไม่ซ้ำใคร

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

คุณสมบัติของวัตถุและคอลเลกชัน

เพื่อที่จะเข้าถึงคุณสมบัติใดๆ ของอ็อบเจ็กต์โดยตรง ก็เพียงพอแล้วที่จะเพิ่มชื่อคุณสมบัติให้กับพาธไปยังอ็อบเจ็กต์ เช่น รับชื่อผู้ใช้ /users/25/name วิธีการ GET (รับค่า) และ PUT/PATCH (เปลี่ยนค่า) ใช้ได้กับคุณสมบัติ วิธีการ DELETE ใช้ไม่ได้เนื่องจาก คุณสมบัติเป็นส่วนโครงสร้างของวัตถุในฐานะหน่วยข้อมูลที่เป็นทางการ

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

คอลเลกชันของวัตถุที่เกี่ยวข้อง

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

หน้าที่ของวัตถุและคอลเลกชัน

ในการสร้างเส้นทางไปยังอินเทอร์เฟซการเรียกใช้ฟังก์ชันของคอลเลกชันหรือวัตถุ เราใช้วิธีการเดียวกันกับการเข้าถึงคุณสมบัติ ตัวอย่างเช่น สำหรับอ็อบเจ็กต์ /users/25/sendPasswordReminder หรือคอลเล็กชัน /users/disableUnconfirmed สำหรับการเรียกใช้ฟังก์ชัน เราจะใช้วิธี POST เสมอ ทำไม ฉันขอเตือนคุณว่าใน REST แบบคลาสสิกไม่มีคำกริยาพิเศษสำหรับเรียกใช้ฟังก์ชัน ดังนั้นเราจะต้องใช้หนึ่งในคำกริยาที่มีอยู่ ในความคิดของฉัน วิธี POST เหมาะสมที่สุดสำหรับสิ่งนี้ เพราะ... ช่วยให้คุณสามารถส่งผ่านอาร์กิวเมนต์ที่จำเป็นไปยังเซิร์ฟเวอร์ ไม่ใช่ idempotent (ส่งคืนผลลัพธ์เดียวกันเมื่อเข้าถึงหลายครั้ง) และเป็นนามธรรมที่สุดในซีแมนทิกส์

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

การประมาณที่สาม: คำถามและคำตอบ

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

คำตอบสากล

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

ความสำเร็จ - เครื่องหมายของความสำเร็จของคำขอ

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

POST /api/v1/articles/22/publish ("ความสำเร็จ": จริง)

ข้อผิดพลาด - ข้อมูลข้อผิดพลาด

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

GET /api/v1/user ("success": false, "error": ("code": 401, "message": "การอนุญาตล้มเหลว"))

ข้อมูล - ข้อมูลที่ส่งคืนโดยเซิร์ฟเวอร์

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

ตัวอย่างข้อมูลที่ส่งคืนหากสำเร็จ ในกรณีนี้ การตอบสนองจะมีออบเจ็กต์ผู้ใช้ที่ร้องขอ

รับ /api/v1/user ("success": true, "data": ( "id": 125, "email": " [ป้องกันอีเมล], "ชื่อ" : "จอห์น", "นามสกุล" : "สมิธ", ) )

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

PUT /api/v1/user ( "success": false, "error": ( "code" : 422, "message" : "Validation failed" ) "data": ( "email" : "อีเมลไม่สามารถเว้นว่างได้ ", ) )

การแบ่งหน้า - ข้อมูลที่จำเป็นในการจัดระเบียบการนำทางหน้า

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

ชุดค่าขั้นต่ำสำหรับการแบ่งหน้าประกอบด้วย:

• จำนวนบันทึกทั้งหมด
• จำนวนหน้า;
• หมายเลขหน้าปัจจุบัน
• จำนวนบันทึกต่อหน้า
• จำนวนบันทึกสูงสุดต่อหน้าที่ฝั่งเซิร์ฟเวอร์รองรับ

นักพัฒนาเว็บ API บางรายยังรวมชุดลิงก์สำเร็จรูปไปยังหน้าที่ติดกันไว้ในการแบ่งหน้า รวมถึงลิงก์แรก สุดท้าย และปัจจุบัน

GET /api/v1/articles การตอบสนอง: ( "success": true, "data": [ ( "id" : 1, "title" : "Interesting thing", ), ( "id" : 2, "title" : "ข้อความที่น่าเบื่อ", ) ], "การแบ่งหน้า": ( "totalRecords" : 2, "totalPages" : 1, "currentPage" : 1, "perPage" : 20, "maxPerPage" : 100, ) )

ทำงานกับข้อผิดพลาด

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

อะไรคือสาเหตุที่เป็นไปได้สำหรับข้อยกเว้นที่คุณได้รับ?

500 ข้อผิดพลาดเซิร์ฟเวอร์ภายใน - ทุกอย่างเสียหาย แต่เราจะแก้ไขในไม่ช้า

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

400 คำขอไม่ถูกต้อง - และตอนนี้ทุกอย่างพังเพื่อคุณ

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

401 ไม่ได้รับอนุญาต - คนแปลกหน้าระบุตัวตน

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

403 ต้องห้าม - คุณไม่ได้รับอนุญาตที่นี่

มีทรัพยากรที่ร้องขออยู่ แต่ผู้ใช้ไม่มีสิทธิ์เพียงพอที่จะดูหรือแก้ไข

404 ไม่พบ - ไม่มีใครอาศัยอยู่ตามที่อยู่นี้

ตามกฎแล้วการตอบสนองดังกล่าวจะถูกส่งกลับในสามกรณี: เส้นทางไปยังทรัพยากรไม่ถูกต้อง (ผิดพลาด) ทรัพยากรที่ร้องขอถูกลบและหยุดอยู่ สิทธิ์ของผู้ใช้ปัจจุบันไม่อนุญาตให้เขาทราบเกี่ยวกับการมีอยู่ ของทรัพยากรที่ร้องขอ ตัวอย่างเช่น ในขณะที่เรากำลังดูรายการผลิตภัณฑ์ จู่ๆ หนึ่งในนั้นก็ดูล้าสมัยและถูกถอดออก

ไม่อนุญาตให้ใช้วิธี 405 - คุณไม่สามารถทำได้

ข้อยกเว้นประเภทนี้เกี่ยวข้องโดยตรงกับคำกริยาที่ใช้ในคำขอ (GET, PUT, POST, DELETE) ซึ่งในทางกลับกันจะบ่งบอกถึงการกระทำที่เราพยายามดำเนินการกับทรัพยากร หากทรัพยากรที่ร้องขอไม่รองรับการกระทำที่ระบุ เซิร์ฟเวอร์จะแจ้งอย่างชัดเจน

422 เอนทิตีที่ไม่สามารถประมวลผลได้ - แก้ไขและส่งอีกครั้ง

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

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

คำขอ

กำลังดึงรายการคอลเลกชัน

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

การนำทางหน้า

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

รับ /api/v1/news?page=1

ต่อหน้า- ระบุจำนวนองค์ประกอบที่ต้องการบนหน้า โดยทั่วไป API จะมีค่าเริ่มต้นของตัวเอง ซึ่งจะส่งกลับเป็นฟิลด์ perPage ในส่วนการแบ่งหน้า แต่ในบางกรณี API จะอนุญาตให้คุณเพิ่มค่านี้เป็นขีดจำกัดที่สมเหตุสมผลโดยระบุค่าสูงสุด maxPerPage:

รับ /api/v1/news?perPage=100

การเรียงลำดับผลลัพธ์

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

เรียงลำดับตาม- มีหลายวิธีในการส่งข้อมูลการเรียงลำดับที่ซับซ้อนในพารามิเตอร์ GET ที่นี่จำเป็นต้องระบุลำดับและทิศทางการเรียงลำดับอย่างชัดเจน

API บางตัวแนะนำให้ทำเช่นนี้เป็นสตริง:

รับ /api/v1/products?sortBy=name.desc,price.asc

ตัวเลือกอื่นแนะนำให้ใช้อาร์เรย์:

รับ /api/v1/ผลิตภัณฑ์? sortBy=name& sortBy=desc& sortBy=price& sortBy=asc

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

การกรองอย่างง่ายตามค่า

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

รับ /api/v1/articles?authorId=25

ตัวเลือกการกรองขั้นสูง

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

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

รับ /api/v1/products?price=500&price=1000

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

รับ /api/v1/products?status=1&status=2

การกรองตามการจับคู่สตริงบางส่วน ใช้กับฟิลด์ที่มีข้อมูลข้อความหรือข้อมูลที่สามารถเทียบได้กับข้อความ เช่น SKU ของผลิตภัณฑ์ที่เป็นตัวเลข หมายเลขโทรศัพท์ เป็นต้น

GET /api/v1/users?name=John GET /api/v1/products?code=123

ตัวกรองที่มีชื่อ

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

รับ /api/v1/products?filters=recommended

ตัวกรองที่มีชื่อสามารถมีพารามิเตอร์ของตัวเองได้

รับ /api/v1/products?filters=kidds

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

ฐานข้อมูลที่ทำงานโดยใช้เทคโนโลยี FILE SERVER

ฐานข้อมูลที่ใช้เทคโนโลยี CLIENT-SERVER

ไฟล์เซิร์ฟเวอร์

- การเข้าถึงฐานข้อมูล (แบบสอบถาม)
- การถ่ายโอนข้อมูลในขณะที่บล็อกการเข้าถึงของผู้ใช้รายอื่น
- การประมวลผลข้อมูลบนคอมพิวเตอร์ของผู้ใช้

เพื่อความชัดเจน ลองดูตัวอย่างที่เฉพาะเจาะจง สมมติว่าคุณต้องดูคำสั่งจ่ายเงินที่ส่งในช่วงวันที่ 19 พฤษภาคมถึง 25 พฤษภาคมเป็นจำนวน 5,000 รูเบิล ผู้ใช้จะต้องเปิดแอปพลิเคชันไคลเอนต์บนคอมพิวเตอร์ของเขาซึ่งทำงานในฐานข้อมูลพร้อมคำสั่งการชำระเงิน และป้อนเกณฑ์การคัดเลือกที่จำเป็น หลังจากนั้นไฟล์ที่มีเอกสารประเภทนี้ทั้งหมดตลอดระยะเวลาในจำนวนเท่าใดก็ได้จะถูกดาวน์โหลดไปยังคอมพิวเตอร์ของคุณจากเซิร์ฟเวอร์ฐานข้อมูลและโหลดลงใน RAM แอปพลิเคชันไคลเอนต์ที่ทำงานบนคอมพิวเตอร์ของผู้ใช้ที่ทำงานร่วมกับฐานข้อมูลจะประมวลผลข้อมูลนี้ (เรียงลำดับ) จากนั้นให้การตอบกลับ (รายการคำสั่งชำระเงินที่ตรงตามเกณฑ์ของคุณจะปรากฏบนหน้าจอ) หลังจากนี้ คุณจะเลือกคำสั่งการชำระเงินที่ต้องการและลองแก้ไข (เปลี่ยนแปลง) ฟิลด์หนึ่งในนั้น - ตัวอย่างเช่นวันที่ ในระหว่างการแก้ไข แหล่งข้อมูลจะถูกบล็อก นั่นคือไฟล์ทั้งหมดที่มีเอกสารนี้ ซึ่งหมายความว่าไฟล์จะไม่สามารถใช้ได้สำหรับผู้ใช้รายอื่นเลยหรือจะสามารถใช้ได้เฉพาะในโหมดดูเท่านั้น ยิ่งไปกว่านั้น การจับภาพประเภทนี้ไม่ได้เกิดขึ้นในระดับบันทึกด้วยซ้ำ นั่นคือ เอกสารเดียว แต่ไฟล์ทั้งหมดถูกล็อค นั่นคือทั้งตารางที่มีเอกสารที่คล้ายกัน หลังจากที่ฟิลด์นี้ได้รับการประมวลผลอย่างสมบูรณ์และออกจากโหมดการแก้ไขแล้วเท่านั้น ไฟล์ใบสั่งการชำระเงินนี้จะถูกปลดล็อคจากการถูกบันทึกโดยผู้ใช้ หากข้อมูลถูกจัดเก็บไว้ในออบเจ็กต์ขนาดใหญ่ เช่น ไฟล์หนึ่งมีคำสั่งจ่ายเงินสำหรับทั้งการรับเงินและการส่งเงิน ก็จะไม่มีข้อมูลมากกว่านี้อีก คุณจะทำงานกับช่อง "วันที่" หนึ่งช่องในเอกสารเดียว - พนักงานในองค์กรที่เหลือจะรอจนกว่าคุณจะดำเนินการเสร็จ

ข้อเสียของระบบ FILE SERVER นั้นชัดเจน:

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

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

การล็อกข้อมูลเมื่อแก้ไขโดยผู้ใช้รายหนึ่งทำให้ผู้ใช้รายอื่นไม่สามารถทำงานกับข้อมูลนี้ได้

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

ไคลเอนต์เซิร์ฟเวอร์

กำลังประมวลผลคำขอของผู้ใช้รายเดียว:
- การเข้าถึงฐานข้อมูล (แบบสอบถาม SQL)
- การส่งการตอบสนอง - ผลลัพธ์ของการประมวลผล




หากจำเป็นต้องประมวลผลข้อมูลที่เก็บไว้ในฐานข้อมูล แอปพลิเคชันไคลเอ็นต์ที่ทำงานบนคอมพิวเตอร์ของผู้ใช้ที่ทำงานร่วมกับฐานข้อมูลจะสร้างแบบสอบถามในภาษา SQL (ชื่อจากตัวอักษรเริ่มต้น - Structured Query Language) เซิร์ฟเวอร์ฐานข้อมูลยอมรับคำขอและดำเนินการอย่างอิสระ ไม่มีการส่งอาร์เรย์ข้อมูล (ไฟล์) ผ่านเครือข่าย หลังจากประมวลผลคำขอ เฉพาะผลลัพธ์เท่านั้นที่จะถูกโอนไปยังคอมพิวเตอร์ของผู้ใช้ นั่นคือในตัวอย่างก่อนหน้านี้ รายการคำสั่งการชำระเงินที่ตรงตามเกณฑ์ที่จำเป็น ตัวไฟล์ซึ่งมีข้อมูลที่ทำหน้าที่เป็นแหล่งที่มาสำหรับการประมวลผลถูกเก็บไว้ ยังคงไม่ถูกบล็อกเพื่อให้เซิร์ฟเวอร์เข้าถึงได้ตามคำขอของผู้ใช้รายอื่น

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

ดังนั้นข้อเสียข้างต้นทั้งหมดของโครงร่าง FILE-SERVER จึงถูกกำจัดในสถาปัตยกรรม CLIENT-SERVER:

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

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

ข้อมูลไม่ถูกบล็อก (บันทึก) โดยผู้ใช้รายเดียว

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

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

ประเภทของข้อมูลที่สามารถจัดเก็บในฐานข้อมูลได้ (ตัวเลข วันที่ ข้อความ รูปภาพ วีดีโอ เสียง ฯลฯ)

เกี่ยวกับเทคโนโลยีที่จัดโดยฐานข้อมูลเองเพื่อเข้าถึงข้อมูลในฐานข้อมูลและระดับการป้องกันข้อมูลจากการเข้าถึงโดยไม่ได้รับอนุญาต

เกี่ยวกับเครื่องมือและวิธีการในการพัฒนาที่สามารถนำมาใช้ในการออกแบบระบบสารสนเทศใด ๆ บนพื้นฐานของฐานข้อมูลนี้

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

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

ตามความเร็ว - เวลาที่ใช้ในการเข้าถึงและประมวลผลข้อมูล

ถ้าเป็นไปได้ จัดระเบียบงานบนคอมพิวเตอร์จากผู้ผลิตหลายราย นั่นคือ ความเข้ากันได้กับแพลตฟอร์มและระบบปฏิบัติการอื่น

ตามระดับการสนับสนุน (บริการ) ที่จัดทำโดยผู้พัฒนาฐานข้อมูลหรือตัวแทนจำหน่ายที่ได้รับอนุญาต

ความพร้อมของเครื่องมือที่ดีสำหรับการสร้างแอปพลิเคชันที่ใช้ฐานข้อมูลนี้ ฯลฯ

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

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

หลักการพื้นฐานของเทคโนโลยีไคลเอนต์-เซิร์ฟเวอร์คือการแบ่งฟังก์ชันแอปพลิเคชันออกเป็นสามกลุ่ม:

· การป้อนข้อมูลและการแสดงผล (การโต้ตอบของผู้ใช้)

· ฟังก์ชันที่ประยุกต์ใช้กับสาขาวิชาที่กำหนด

· ฟังก์ชันการจัดการทรัพยากร (ระบบไฟล์ ฐานข้อมูล ฯลฯ)

ดังนั้นในการใช้งานใด ๆ ส่วนประกอบต่อไปนี้จึงมีความโดดเด่น:

· องค์ประกอบการนำเสนอข้อมูล

· ส่วนประกอบแอปพลิเคชัน

· องค์ประกอบการจัดการทรัพยากร

การสื่อสารระหว่างส่วนประกอบต่างๆ ดำเนินการตามกฎเกณฑ์บางประการ ซึ่งเรียกว่า "โปรโตคอลการโต้ตอบ"

5.1.2. โมเดลการโต้ตอบระหว่างไคลเอนต์และเซิร์ฟเวอร์

Gartner Group ซึ่งเป็นบริษัทที่เชี่ยวชาญด้านการวิจัยเทคโนโลยีสารสนเทศ ได้เสนอการจำแนกประเภทของโมเดลการโต้ตอบระหว่างไคลเอนต์และเซิร์ฟเวอร์แบบสองระดับดังต่อไปนี้ (โมเดลเหล่านี้เรียกว่าสองระดับเนื่องจากส่วนประกอบทั้งสามของแอปพลิเคชันมีการกระจายที่แตกต่างกันระหว่างสองโหนด ):

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

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

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

ต่อมา แนวคิดของเซิร์ฟเวอร์ที่ใช้งานอยู่ได้รับการพัฒนา ซึ่งใช้กลไกขั้นตอนการจัดเก็บ สิ่งนี้ทำให้ส่วนหนึ่งของส่วนประกอบแอปพลิเคชันถูกถ่ายโอนไปยังเซิร์ฟเวอร์ (โมเดลแอปพลิเคชันแบบกระจาย) ขั้นตอนจะถูกจัดเก็บไว้ในพจนานุกรมฐานข้อมูล แชร์ระหว่างไคลเอนต์หลายตัว และดำเนินการบนคอมพิวเตอร์เครื่องเดียวกันกับเซิร์ฟเวอร์ SQL ข้อดีของแนวทางนี้: การบริหารฟังก์ชันแอปพลิเคชันแบบรวมศูนย์เป็นไปได้ การรับส่งข้อมูลเครือข่ายจะลดลงอย่างมาก (เนื่องจากการเรียกไปยังกระบวนงานที่เก็บไว้จะถูกส่งมากกว่าการสืบค้น SQL) ข้อเสียคือเครื่องมือที่จำกัดในการพัฒนาขั้นตอนการจัดเก็บเมื่อเปรียบเทียบกับภาษาวัตถุประสงค์ทั่วไป (C และ Pascal)

ในทางปฏิบัติ ปัจจุบันมักใช้แนวทางแบบผสม:

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

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

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

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

5.1.3. การตรวจสอบธุรกรรม

ในกรณีที่ระบบสารสนเทศรวมแหล่งข้อมูลและเซิร์ฟเวอร์แอปพลิเคชันที่แตกต่างกันจำนวนมากเพียงพอ คำถามก็เกิดขึ้นเกี่ยวกับการจัดการส่วนประกอบทั้งหมดอย่างเหมาะสมที่สุด ในกรณีนี้ มีการใช้เครื่องมือพิเศษ - มอนิเตอร์การประมวลผลธุรกรรม (มักเรียกง่ายๆว่า "มอนิเตอร์ธุรกรรม") ในขณะเดียวกัน แนวคิดของธุรกรรมก็ขยายออกไปเมื่อเทียบกับสิ่งที่ทราบในทฤษฎีฐานข้อมูล ในกรณีนี้ นี่ไม่ใช่การดำเนินการแบบอะตอมมิกในฐานข้อมูล แต่เป็นการดำเนินการใดๆ ในระบบ เช่น การออกข้อความ การเขียนลงในไฟล์ดัชนี การพิมพ์รายงาน ฯลฯ

ในการสื่อสารระหว่างแอปพลิเคชันโปรแกรมและการตรวจสอบธุรกรรม จะใช้ API เฉพาะ (Application Program Interface) ซึ่งใช้เป็นไลบรารีที่มีการเรียกไปยังฟังก์ชันพื้นฐาน (สร้างการเชื่อมต่อ เรียกใช้บริการเฉพาะ ฯลฯ) แอปพลิเคชันเซิร์ฟเวอร์ (บริการ) ก็ถูกสร้างขึ้นโดยใช้ API นี้เช่นกัน แต่ละบริการจะได้รับการกำหนดชื่อที่ไม่ซ้ำกัน การตรวจสอบธุรกรรมที่ได้รับคำขอจากแอปพลิเคชันโปรแกรม จะส่งผ่านการโทรไปยังบริการที่เหมาะสม (หากไม่ได้ทำงานอยู่ กระบวนการที่จำเป็นจะเกิดขึ้น) และหลังจากประมวลผลคำขอโดยแอปพลิเคชันเซิร์ฟเวอร์แล้ว ก็จะส่งคืนผลลัพธ์ไปที่ ลูกค้า. โปรโตคอล XA ได้รับการพัฒนาสำหรับการโต้ตอบของการตรวจสอบธุรกรรมกับเซิร์ฟเวอร์ฐานข้อมูล การมีอินเทอร์เฟซแบบรวมดังกล่าวทำให้สามารถใช้ DBMS ที่แตกต่างกันหลายตัวภายในแอปพลิเคชันเดียวได้

การใช้การมอนิเตอร์ธุรกรรมบนระบบขนาดใหญ่ให้ประโยชน์ดังต่อไปนี้:

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

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

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

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

· เป็นไปได้ที่จะจัดการฐานข้อมูลแบบกระจาย (สำหรับรายละเอียดเพิ่มเติม ดูย่อหน้าถัดไป)

5.2. กำลังประมวลผลข้อมูลที่กระจาย

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

มีสองวิธีในการจัดการประมวลผลข้อมูลแบบกระจาย

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

2. เทคโนโลยีการจำลองแบบในกรณีนี้ ข้อมูลของคอมพิวเตอร์ทุกเครื่องจะถูกทำซ้ำในแต่ละโหนดเครือข่าย ในกรณีนี้:

· เฉพาะการดำเนินการแก้ไขข้อมูลเท่านั้นที่จะถูกส่ง ไม่ใช่ตัวข้อมูลเอง

· การส่งข้อมูลสามารถเป็นแบบอะซิงโครนัส (ไม่พร้อมกันสำหรับโหนดที่แตกต่างกัน)

· ข้อมูลอยู่ในตำแหน่งที่มีการประมวลผล

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