ประสิทธิภาพเป็นเหตุผลเดียวที่ไม่ใช้ SignalR (websockets) ทั้งหมดแทน REST API แบบดั้งเดิมหรือไม่

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

อย่างน้อยที่สุดสิ่งล่อใจสำหรับฉันคือการละทิ้งการพัฒนาบริการ Web API และใช้SignalRสำหรับทุกสิ่ง

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

ดังนั้นฉันอยากรู้ว่า:

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

มันเป็นความฝันของฉันมานานแล้วที่จะสามารถแปลวัตถุฝั่งเซิร์ฟเวอร์และคำจำกัดความการบริการเป็นรหัสการเข้าถึงบริการฝั่งไคลเอ็นต์โดยไม่มีอะไรโง่node.jsๆ ตัวอย่างเช่นถ้าฉันกำหนดวัตถุที่น่าสนใจInterestingObjectและบริการไปCRUDยังวัตถุInterestingObjectServiceฉันสามารถกำหนดเส้นทาง URL มาตรฐานไปยังบริการ - พูดว่า "/ {serviceName} / {methodName}" - แต่ฉันยังคงต้องเขียนรหัสลูกค้าเพื่อเข้าถึง บริการ. เนื่องจากวัตถุจะถูกส่งผ่านจากไคลเอนต์ไปยังเซิร์ฟเวอร์และย้อนกลับจึงไม่มีเหตุผลเชิงปฏิบัติที่จะมีเพื่อกำหนดวัตถุอย่างชัดเจนในรหัสฝั่งไคลเอ็นต์และไม่จำเป็นต้องกำหนดเส้นทางเพื่อดำเนินการ CRUD อย่างชัดเจน ฉันรู้สึกว่าควรมีวิธีที่จะทำให้มาตรฐานทั้งหมดนี้เป็นไปได้ในการเขียนไคลเอนต์ภายใต้สมมติฐานที่ว่าการเข้าถึงบริการทำงานจากไคลเอนต์ไปยังเซิร์ฟเวอร์และกลับมาอย่างโปร่งใสเหมือนที่ฉันเขียน WinForms หรือ Java Applet หรือ Native App หรือสิ่งที่มีคุณ

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

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

เทคโนโลยีทั้งสองนั้นมีจุดประสงค์ที่แตกต่างกันมาก

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

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

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

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

แต่การแลกเปลี่ยนของพวกเขามาในราคา:

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

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

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

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

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

ซ็อกเก็ตเว็บยังคงมีการสนับสนุนที่ จำกัดและไม่สามารถนำไปใช้ได้ง่ายเสมอไป แม้ว่า SignalR จะทำให้ใช้งานได้ง่าย แต่ก็ไม่ได้หมายความว่าคุณจะไม่มีปัญหาในการใช้งานในภาษาอื่น ๆ บริบท / สภาพแวดล้อมอื่น ๆ ด้วย REST นั้นง่าย: อาจเป็นcurlสายหรือคุณสมบัติที่คล้ายกันในทุกภาษาหลัก ด้วยซ็อกเก็ตเว็บคุณจะไม่สามารถมั่นใจได้ว่าจะใช้เวลานานเท่าใดในการสร้างลูกค้าโดยใช้ [ใส่ชื่อของภาษาที่คุณยังไม่รู้ที่นี่]

ฉันใช้ซ็อกเก็ตเว็บในหลายโครงการใน. NET, Python และ node.js

• ใน. NET มันไม่ได้ยากเกินไป แต่ถึงกระนั้นฉันยังคงใช้เวลาสองสามวันในการหาปัญหาเกี่ยวกับความลับเช่นการเชื่อมต่อลดลงทันทีที่เปิด (นี่คือก่อนที่จะ SignalR; ฉันไม่เคยลอง SignalR) ฉันยังใช้ WCF ในโหมดเว็บซ็อกเก็ตซึ่งไม่ได้มีปัญหาใด ๆ (แต่ฉันเชื่อว่า WCF มักจะมาพร้อมกับปัญหา)

• ใน node.js สิ่งนี้ทำได้ แต่ฉันต้องเปลี่ยนห้องสมุดเป็นสองเท่าจนกว่าฉันจะพบที่ทำงาน ฉันเชื่อว่าฉันใช้เวลาอย่างน้อยหนึ่งสัปดาห์ในการสร้างเว็บซ็อกเก็ต Hello World

• ใน Python ฉันพยายามหนึ่งครั้งใช้เวลาสองหรือสามวันและถูกทอดทิ้ง มันไม่เคยทำงาน

เปรียบเทียบสิ่งนี้กับ REST: ปัญหาเดียวที่สามารถพบได้กับภาษา / กรอบงานใหม่คือการรู้วิธีการโพสต์ไฟล์หรือรับการตอบกลับไบนารีที่มีขนาดใหญ่มาก ฉันจำได้ว่าใช้เวลาสองสามชั่วโมงเพื่อค้นหาวิธีแก้ปัญหาสำหรับบางภาษา ยังไม่กี่ชั่วโมงสำหรับกรณีพิเศษคือไม่มีอะไรเทียบกับวันหรือสัปดาห์สำหรับ Hello World ง่ายๆ

แค่ 2 เซ็นต์ของฉัน ...

ฉันคิดว่ามันไม่ได้เกี่ยวกับการแสดงหรืออะไรก็ตาม มันเกี่ยวกับมาตรฐาน REST เป็นมาตรฐานและ IMHO มีข้อดีดังต่อไปนี้:

• การร้องขอ HTTP นั้นง่ายต่อการใช้งาน ทุกคนสามารถใช้ REST API ได้อย่างรวดเร็ว เฮ้, คุณสามารถเปิดเบราว์เซอร์และพิมพ์ URL เพื่อดูข้อมูล, คุณโต้ตอบได้มากแค่ไหน?
• (เกือบ) ภาษาการเขียนโปรแกรมใด ๆ ที่สามารถใช้งานได้ มันเป็นอินเทอร์เฟซสากล การเชื่อมต่อกับ SignalR จากภาษาแปลกใหม่ดูเหมือนจะไม่ค่อยชัดเจน
• มีการรองรับการใช้เครื่องมือที่ดีเช่นhttp://petstore.swagger.wordnik.com/
• เป็น "อินเทอร์เฟซ" ที่ดีในการแก้ไขข้อบกพร่อง คุณสามารถตรวจสอบข้อความขาเข้าและขาออกได้อย่างง่ายดายโดยตรงในเบราว์เซอร์ดูข้อมูล ฯลฯ ด้วย websockets และไลบรารีที่กำหนดเองมันไม่ชัดเจนคุณต้องบันทึกทุกอย่างอย่างชัดเจน