RESTful HTTP และ websocket ในแอปพลิเคชันเดียวกันหรือไม่

หากแอปพลิเคชันเปิดWebSocketฟีดสดอยู่แล้วฉันควรใช้แอปพลิเคชันนั้นAJAXเพื่อการสื่อสารอื่น ๆ กับเซิร์ฟเวอร์หรือไม่

เนื่องจากการเชื่อมต่อเปิดอยู่แล้วเราควรใช้สำหรับการร้องขอที่Request/Responseไม่ใช่แบบเรียลไทม์หรือไม่

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

มันจะแปลกที่จะมีRESTful HTTP APIและWebSocketในการประยุกต์ใช้กันได้หรือไม่

rest ajax websockets

— มาร์ค
แหล่งที่มา

"คุณไม่ต้องเขียนโค้ดใด ๆ เพื่อทดสอบ API" คุณช่วยอธิบายอีกหน่อยได้ไหม? อะไรทำให้คุณคิดว่าคุณไม่จำเป็นต้องทดสอบ API

— Elias Van Ootegem

เครื่องมือสำหรับนักพัฒนาซอฟต์แวร์ของ Chrome หากฉันไม่เข้าใจผิดให้คุณเปิด websocket และส่งข้อความตามเวลาจริง

— maple_shaft

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

— Marc

@maple_shaft ดี แต่คุณต้องอยู่ในหน้าเว็บที่เปิด WebSocket ไปยังเซิร์ฟเวอร์

— Marc

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

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

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

— maple_shaft
แหล่งที่มา

นั่นคือสิ่งที่ฉันสงสัย มันสมเหตุสมผลที่จะใช้ websockets สำหรับฟีดสดแบบเรียลไทม์ แต่สิ่งที่เกี่ยวกับการทำงานของ CRUD? ในใจของฉันมีเหตุผลที่จะใช้คำขอ HTTP มาตรฐานสำหรับผู้ที่

— Marc

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

— Myst

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

— PirateApp