นี่คือ "รูปแบบต่อต้าน" และฉันควรหยุดใช้หรือออกแบบที่ฉลาดนี้หรือไม่?


10

ฉันมักจะทำต่อไปนี้เมื่อสร้างบริการ REST:

  1. มีการร้องขอ HTML
  2. บริการส่งคืนหน้าเว็บที่ต้องการ แต่ไม่มี "ทรัพยากร" ที่ร้องขอเช่น ข้อมูล
  3. หน้าเว็บมี JavaScript ที่ออกคำขอ AJAX ไปยังบริการเดียวกัน (ประเภทเนื้อหาที่แตกต่างกัน)
  4. บริการจะส่งคืนข้อมูลจริง (JSON) และหน้าแสดงข้อมูลนั้น

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

เหตุผลที่ฉันลงเอยด้วยเหตุผลนี้ก็คือหน้าเว็บนั้นเกือบจะบริสุทธิ์ Html + JavaScript และแทบจะไม่จำเป็นต้องมีสิ่งที่ฝั่งเซิร์ฟเวอร์โดยเฉพาะอย่างยิ่งไม่มีการวนซ้ำเพื่อสร้างตารางและสิ่งต่าง ๆ เช่นนั้น (ซึ่งฉันคิดว่าน่าเกลียดมาก เช่น slickgrid) เช่นการแยกข้อมูลและมุมมอง

ตอนนี้ก่อนที่ฉันจะใช้สิ่งนี้เป็นความคิดที่ดีหรือฉันควรหยุดทำหรือไม่


2
ถ้าคุณต้องการใช้เวลากับคนที่คุณรักมากขึ้นและคุณต้องการที่จะมีเวลาสนุกกับงานอดิเรกหรือทำตามเป้าหมายส่วนตัวเพื่อประโยชน์ของพระเจ้า: อย่าใช้โปรแกรมเช่นนั้น! แต่ถ้าคุณชอบอยู่ดึกดื่นและสุดสัปดาห์ในสำนักงานเพื่อรักษารหัส "ฉลาด" ไว้มากมาย
Tulains Córdova

3
คุณสามารถอธิบายสิ่งที่คุณคิดว่าเลวร้ายโดยเฉพาะได้ไหม บริบท: นี่ไม่ใช่สัตว์ร้าย 10 Mio LOC ซึ่งสำคัญกับธุรกิจ มันเหมือน <5000 LOC และไม่สำคัญว่ามันจะไม่ทำงานสักสองสามวัน ใช่นั่นไม่ใช่สิ่งที่ฉันควรทำสิ่งที่เส็งเคร็งดังนั้นควรอธิบายสิ่งที่คุณคิดว่าแย่มาก
เริ่มต้น

@begginer_ ทุกซอฟต์แวร์เริ่มต้นเล็ก สิ่งที่คุณอธิบาย rseembles Rube Goldberg Machine: hammer hits man, man drop บิสกิต, บิสกิตนกแก้วคว้าและ tilts แจกัน ฯลฯ
Tulains Córdova

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

คุณใช้บริการนี้จากลูกค้าเช่นสคริปต์หรือจาก curl อย่างไร สิ่งเหล่านั้นไม่มีล่ามจาวาสคริปต์ นี่เป็นบริการสำหรับเบราว์เซอร์เท่านั้นหรือไม่
ไบรอัน Oakley

คำตอบ:


17

หากคุณร้องขอทรัพยากรและไม่มีข้อมูลมากกว่าที่จะไม่ใช่บริการ REST บริการที่ให้ข้อมูลจริงใน json อาจเป็น แต่ส่วน HTML ไม่ใช่ สำหรับเว็บแอปพลิเคชันมันไม่สำคัญ

เทคนิคใช้งานได้ แต่คุณจำเป็นต้องตระหนักถึงข้อ จำกัด ดังกล่าว:

  1. เครื่องมือค้นหาไม่ตีความ JavaScript ดังนั้นไซต์ที่ใช้งานเช่นนั้นจะไม่สามารถสร้างดัชนีโดย Google และไลค์ สำหรับแอปพลิเคชันภายในมันไม่สำคัญสำหรับสาธารณะที่ต้องเผชิญกับมันจะสำคัญ
  2. ผู้ใช้ที่มีความต้องการพิเศษ (เช่นผู้ที่ใช้เทอร์มินัลของ Braille) ใช้เบราว์เซอร์พิเศษที่ค่อนข้าง จำกัด และอาจแปล JavaScript ไม่ถูกต้อง

ฉันจะทราบด้วยว่าโค้ดที่สร้าง HTML นั้นเหมือนกันไม่ว่าจะรันฝั่งเซิร์ฟเวอร์หรือฝั่งไคลเอ็นต์ คุณมีตัวเลือกที่ใหญ่กว่าทั้งภาษาและกรอบงานบนฝั่งเซิร์ฟเวอร์และฉันมั่นใจว่ามีหลาย ๆ slickgrid ที่เทียบเท่ากัน

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

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


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

ทำไมมันถึงไม่เหลือ
dagnelies

1
หากคุณแยกความแตกต่างระหว่าง "ข้อมูล" ซึ่งเป็นแอปพลิเคชัน (HTML, JS, CSS, ฯลฯ ) และ "ข้อมูล" ซึ่งแอปพลิเคชันแสดง (JSON) ส่วน JSON คือ REST แต่ส่วนที่โหลด "รหัส" isn ' เสื้อ หากคุณเห็นสิ่งทั้งหมดเป็นนามธรรมมากกว่าทั้งคู่
เค ..

2

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


2
Apache เป็น overkill สำหรับเนื้อหาคงที่ มีเซิร์ฟเวอร์ที่เร็วกว่ามาก ที่นิยมมากที่สุดน่าจะเป็นNginx
Jan Hudec

5
นั่นคือตัวอย่างไม่มีอะไรเพิ่มเติม
Steven Schlansker

2

นี่เป็นวิธีปฏิบัติที่ดี และจะทำตลอดเวลาแม้ว่า @JanHudec ชี้ให้เห็นว่าการเรียกใช้บริการ REST นั้นผิด แต่เว็บไซต์จำนวนมากทำสิ่งนี้อย่างแม่นยำด้วยเหตุผลที่คุณชี้ชัด


1
... และเหตุผลใหญ่ที่หลายคนทำก็คงเป็นเพราะการมีปฏิสัมพันธ์ข้อมูลผ่านบริการ / JSON อยู่แล้วดังนั้นจึงมีแนวโน้มที่ดีในการจัดการทั้งหมดของการปฏิสัมพันธ์ข้อมูลของคุณในทางเดียวกัน (เช่นถ้าคุณกำลังใช้ AJAX เพื่อรีเฟรชตาราง ... คุณควรใช้มันเพื่อสร้างตารางในตอนแรก)
Chad Thompson

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

1

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

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

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

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

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


คุณหมายถึงอะไรโดย "random JS" ในกรณีของฉันสิ่งที่คุณกำลังอธิบายข้างต้นมีความซับซ้อนมากขึ้นสิ่งที่ฉันมี (ฟิลด์ป้อนข้อมูลไม่กี่และตาราง (slickgrid) หรือแท็บ jquery ui) อย่างนั้นแหละ. ประมาณ 200 LOC ต่อหน้า
เริ่มต้น

0

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


0

อาจเป็นรูปแบบการต่อต้าน แต่ฉันคิดว่ามันเป็นอนาคตของเว็บแอปพลิเคชัน อย่างไรก็ตามแทนที่จะล้อเล่นกับ JavaScript คุณควรใช้ไลบรารี templating อย่างน้อยที่สุด ทางออกที่ดีกว่าคือกรอบ MVC ฝั่งไคลเอ็นต์เช่นAngularJS (ซึ่งฉันกำลังใช้อยู่ตอนนี้)

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

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


ขอบคุณไม่เคยได้ยิน AngularJS แต่ฉันคิดว่าความต้องการในปัจจุบันของฉันมันมากเกินไป
เริ่มต้น

0

สิ่งที่คุณทำฟังดูดี! อย่างไรก็ตามหากคำตอบ json ของคุณมี HTML ใด ๆ คุณก็เสียเวลา

อีกประเด็นหนึ่งที่เป็นลูกค้าโง่ของคุณอาจจะได้รับข้อมูล json จากโครงการอื่น คุณควรตั้งเป้าหมายแยกระหว่างไคลเอนต์และบริการอย่างเหมาะสมจากนั้นคุณจะได้รับบริการ RESTful ที่เหมาะสม

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