REST หรือคิวข้อความในระบบที่ต่างกันหลายระดับ?

ฉันออกแบบ API REST สำหรับระบบสามชั้นเช่น: Client application-> ->Front-end API cloud serveruser's home API server (Home)

Homeเป็นอุปกรณ์บ้านและควรจะรักษาเชื่อมต่อFront-endผ่าน WebSocket หรือโพลล์ยาว(นี้เป็นสถานที่แรกที่เรากำลังละเมิด REST. จะได้รับก็แย่ภายหลัง) Front-endช่องสัญญาณส่วนใหญ่Clientร้องขอการHomeเชื่อมต่อและจัดการการโทรบางตัว บางครั้งส่งการแจ้งเตือนไปยังHomeClient

Front-endและHomeมี API เดียวกันโดยทั่วไป Clientอาจเชื่อมต่อHomeโดยตรงผ่าน LAN ในกรณีนี้Homeจำเป็นต้องลงทะเบียนClientการกระทำบางอย่างกับFront-endตัวเอง

ข้อดีสำหรับ REST ในระบบนี้คือ:

• REST สามารถอ่านได้โดยมนุษย์
• ส่วนที่เหลือมีการทำแผนที่กริยาที่กำหนดไว้อย่างดี (เช่น CRUD) คำนามและรหัสการตอบสนองกับวัตถุโปรโตคอล;
• มันทำงานผ่าน HTTP และส่งผ่านผู้รับมอบฉันทะที่เป็นไปได้ทั้งหมด;

ส่วนที่เหลือ REST คือ:

• เราไม่เพียง แต่ต้องการสไตล์การสื่อสารที่ตอบสนองการร้องขอเท่านั้น
• รหัสข้อผิดพลาด HTTP อาจไม่เพียงพอสำหรับจัดการข้อผิดพลาดการสื่อสารสามระดับ Front-endอาจจะกลับ202 Acceptedไปโทร async บางเพียงเพื่อจะพบว่าสิ่งที่จำเป็นHomeการเชื่อมต่อถูกทำลายและมีควรจะได้รับ503;
• HomeClientความต้องการที่จะส่งข้อความไปยัง Clientจะต้องสำรวจFront-endหรือเพื่อรักษาการเชื่อมต่อ

เรากำลังพิจารณาWAMP / Autobahnบน Websocket เพื่อรับฟังก์ชั่นการเผยแพร่ / สมัครสมาชิกเมื่อมันทำให้ฉันรู้สึกว่ามันดูเหมือนคิวข้อความอยู่แล้ว

มันคุ้มค่าหรือไม่ที่จะประเมินคิวการส่งข้อความว่าเป็นการขนส่งหรือไม่

ดูเหมือนว่า contras queue message คือ:

• ฉันจะต้องกำหนดคำกริยา CRUD และรหัสข้อผิดพลาดด้วยตัวเองในระดับข้อความ
• ฉันอ่านบางอย่างเกี่ยวกับ "ค่าบำรุงรักษาที่สูงขึ้น" แต่มันหมายความว่าอย่างไร

การพิจารณาเหล่านี้มีความสำคัญเพียงใด

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

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

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

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

ดูเหมือนว่า Autobahn เหมาะสมกับสิ่งที่คุณพยายามทำอย่างมาก มีเครื่องมืออื่น ๆ เช่นกัน ลองใช้Windows Azure Service Bus (ซึ่งมีเฟรมเวิร์กไคลเอ็นต์สำหรับ Java, .NET, PHP, Python, NodeJS และ Ruby)

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

อัปเดตบัญชี 54321 ยอดคงเหลือ = ยอดคงเหลือ - 20.00 ปรับปรุงบัญชี 98765 ยอดคงเหลือ = ยอดคงเหลือ + 20.00

คุณอาจต้องการข้อความเดียวเช่น

โอน 20.00 จากบัญชี 54321 ไปยังบัญชี 98765

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