ความแตกต่างระหว่าง API และส่วนหน้า - ส่วนหลัง


23

ฉันกำลังพยายามเขียนเว็บไซต์ธุรกิจ "มาตรฐาน" โดย "มาตรฐาน" ฉันหมายถึงเว็บไซต์นี้ใช้ HTML5, CSS และ Javascript ปกติสำหรับ front-end, back-end (เพื่อประมวลผลข้อมูล) และรัน MySQL สำหรับฐานข้อมูล มันเป็นเว็บไซต์ CRUD ขั้นพื้นฐาน: Front-end ทำสิ่งที่ฐานข้อมูลมีอยู่ แบ็กเอนด์เขียนไปยังฐานข้อมูลอะไรก็ตามที่ผู้ใช้ป้อนและทำการประมวลผลบางอย่าง เช่นเดียวกับไซต์ส่วนใหญ่ที่ออกมี

ในการสร้างที่เก็บ Github ของฉันที่จะเริ่มต้นการเข้ารหัส, ฉันได้ตระหนักถึงฉันไม่เข้าใจความแตกต่างระหว่างfront-end หลังสิ้นสุดและAPI อีกวิธีในการใช้คำถามของฉันคือ: API เข้ามาในรูปภาพนี้ที่ไหน

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

รายละเอียดเพิ่มเติมบางส่วน:

  • ฉันต้องการลองใช้รูปแบบ Model-View-Controller ฉันไม่รู้ว่านี่เป็นการเปลี่ยนแปลงคำถาม / คำตอบหรือไม่
  • API จะสงบ
  • ฉันต้องการให้back-end ของฉันใช้ API ของตัวเองแทนการอนุญาตให้ back-end โกงและโทรสอบถามพิเศษ ฉันคิดว่าสไตล์นี้มีความสอดคล้องมากกว่า

คำถามของฉัน:

  • ส่วนหน้าเรียกส่วนหลังที่เรียก API หรือไม่ หรือ front-end เพียงเรียก API แทนการโทรกลับหรือไม่
  • back-end เพิ่งรัน API และ API คืนการควบคุมไปยัง back-end (ซึ่ง back-end ทำหน้าที่เป็นตัวควบคุมที่ดีที่สุดการมอบหมายงาน)

คำตอบที่ยาวและละเอียดซึ่งอธิบายบทบาทของ API ควบคู่ไปกับ front-end back-end ได้รับการสนับสนุน หากคำตอบนั้นขึ้นอยู่กับรูปแบบการเขียนโปรแกรม (รุ่นอื่นที่ไม่ใช่รูปแบบ Model-View-Controller) โปรดอธิบายวิธีคิดอื่น ๆ ของ API ขอบคุณ ฉันสับสนมาก

คำตอบ:


25

ฉันคิดว่าคุณกำลังสับสนโดยวิธีการที่ API ถูกใช้ในทางที่ผิดและถูกทารุณกรรมโดยผู้พัฒนาเว็บจำนวนมาก

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

ฉันมีคำถามที่โง่จริงๆ นี่เป็นสาระสำคัญของสถาปัตยกรรมเชิงบริการหรือไม่
johnny

@johnny: ไม่ - SOA เป็นแนวคิดในระดับที่สูงกว่าของนามธรรมมันเป็นเรื่องเกี่ยวกับวิธีที่คุณจัดระเบียบการทำงานของธุรกิจของคุณมากกว่าเกี่ยวกับเลเยอร์ทางเทคนิค
Michael Borgwardt

ฉันจะไม่เรียกมันว่าใช้ในทางที่ผิด อาจจะ "rebranding"? มันเป็นเช่นเดียวกันกับ "MVC" ซึ่งอยู่ในบริบทของการพัฒนาเว็บบางสิ่งที่แตกต่างอย่างสิ้นเชิงกว่าในช่วงเวลาของ PARC เมื่อคำนี้ถูกประกาศเกียรติคุณ
Thomas Junk

9

ให้เราร่างสถาปัตยกรรมของเว็บไซต์ "ทั่วไป" ทั้ง "front-end" และ "back-end" และเนื่องจากเป็นเว็บไซต์เราจะอธิบายได้อย่างชัดเจนว่ามี "ลูกค้า" (เนื่องจากไม่มีวิธีสำหรับ JavaScript ในเบราว์เซอร์ในการโทร MySQL บนเซิร์ฟเวอร์โดยตรง)

เพื่อความชัดเจนคำที่เราใช้คือ:

  • ลูกค้า : เบราว์เซอร์ที่เข้ากันได้กับ HTML5 โดยเฉพาะ โหลด DOM และ JavaScript ที่นั่นเพื่อจัดการมัน
  • Front-End : เซิร์ฟเวอร์ PHP ที่ชี้ไปยัง DOM มีทั้งหน้าแต่ละหน้าที่ร้องขอและจุดเชื่อมต่อสไตล์ AJAX XML หรือ JSON บางสไตล์
  • Back-end : เซิร์ฟเวอร์ฐานข้อมูลที่ MySQL ทำงานอยู่

สำหรับโปรแกรมที่ออกแบบมาอย่างถูกต้องแต่ละองค์ประกอบเหล่านี้มี API ส่วนตัวเพื่อสื่อสารกับผู้อื่น "การ Front-end" โค้ด PHP ไม่ได้ออกโดยพล SQL SELECTงบโดยตรง แต่เรียกเก็บขั้นตอนก่อนได้รับอนุญาต SQL หรือโทร PHP แม้แตกต่างกันไปอินสแตนซ์ที่แตกต่างกันอย่างสิ้นเชิงของ PHP ที่วิ่งบนเซิร์ฟเวอร์ back-end ขั้นตอนการจัดเก็บเหล่านี้หรือการโทร HTTP ที่แตกต่างกันนั้นเป็น API

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

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

API เป็นApplication Programming Interfaceหลังจากทั้งหมดและอ้างอิงจริงๆ เมื่อใดก็ตามที่โปรแกรมหนึ่งเรียกใช้นอกกระบวนการของตัวเอง หากคุณกำลังเขียนโครงการที่มีทั้ง front-end และ back-end ให้เป็น AJAX / PHP / MySQL ดังกล่าวข้างต้นหรือ MS Access / SQL Server มันคุ้มค่าที่จะระบุความชัดเจนว่าคุณจะโทรหากันอย่างไร ถ้าไม่มีเหตุผลอื่นนอกจากจะทำให้ง่ายต่อการรู้ว่าจะดูเมื่อมีอะไรบางอย่างแตก

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


3
ส่วนหน้าจริง ๆ แล้วคือรหัสฝั่งไคลเอ็นต์ (HTML, Javascript) และแบ็กเอนด์คือรหัสเซิร์ฟเวอร์ (PHP, Python, Ruby)
Pithikos

-3

API จัดการคำขอ HTTP เช่น GET, POST, FETCH, DELETE ... ซึ่งสามารถใช้ขึ้นอยู่กับการเข้าถึงโทเค็นของคุณเพื่อดึงข้อมูลในรูปแบบเฉพาะเช่น json, xml เป็นต้น

"data" นี้สามารถใช้ในแอปพลิเคชันของคุณเองเพื่อรับ API (Application Programming Interface) ซึ่งเป็นบริการเว็บสาธารณะที่สามารถเข้าถึงได้เพื่อรวบรวมข้อมูลที่ผู้ชมบางคนอาจสนใจ

ข้อมูลนี้อาจส่งคืนชุดข้อมูลที่แสดงว่าล้มเหลวหรือดึงข้อมูลจากเซิร์ฟเวอร์ API

API มีความหมายว่าเป็นแบ็คเอนด์ดังนั้นจึงสามารถใช้ในสภาพแวดล้อมส่วนหน้าได้ ซึ่งหมายความว่าสามารถใช้ในแอปพลิเคชันบนเว็บ, android, ios ... ที่สามารถรองรับคำขอ https

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.