REST veya çok katmanlı heterojen bir sistemde bir mesaj kuyruğu mu?

Ben üç katmanlı bir sistem için bir REST API tasarlıyorum: Client application-> Front-end API cloud server-> user's home API server (Home).

Homebir ev cihazıdır ve Front-endWebsocket veya uzun bir anketle bağlantıyı sürdürmesi beklenir (bu, REST'i ihlal ettiğimiz ilk yerdir. Daha sonra daha da kötüleşir) . Front-endçoğunlukla tüneller bağlantı Clienttalep eder Homeve bazı çağrıları kendisi yapar. Bazen Homeadresine bildirim gönderir Client.

Front-endve Hometemel olarak aynı API'ye sahip; LAN üzerinden doğrudan Clientbağlanıyor olabilir Home. Bu durumda, Homebazı Clienteylemleri Front-endkendi üzerine kaydetmesi gerekir.

Bu sistemdeki REST'in artıları:

• REST insan tarafından okunabilir;
• REST, protokol nesnelerine fiillerin (CRUD gibi), adların ve yanıt kodlarının iyi tanımlanmış bir eşlemesine sahiptir;
• HTTP üzerinden çalışır ve tüm olası proxy'leri geçirir;

REST kontraları:

• Sadece bir istek-yanıt iletişim stiline değil, aynı zamanda bir yayınla-abone ol seçeneğine de ihtiyacımız var;
• HTTP hata kodları üç katmanlı iletişim hatalarını işlemek için yeterli olmayabilir; yalnızca gerekli bağlantının kesildiğini ve olması gerektiğini öğrenmek için bazı zaman uyumsuz çağrılara Front-enddönebilir ;202 AcceptedHome503
• Homeadresine ileti göndermesi gerekiyor Client. Clientanket yapmak Front-endveya bağlantı kurmak zorunda kalacak .

Biz düşünen WAMP / Autobahn o önceden bir mesaj kuyruğuna gibi bakıyor bana vurunca, işlevsellik Yayın / abonelik almak için WebSocket'e bitti.

Bir tür mesajlaşma kuyruğunu taşıma olarak değerlendirmeye değer mi?

Mesaj kuyruğu kontrasları şu şekildedir:

• CRUD fiillerini ve hata kodlarını kendim bir mesaj düzeyinde tanımlamam gerekecek.
• "Daha yüksek bakım maliyeti" hakkında bir şeyler okudum, ama bu ne anlama geliyor?

bu düşünceler ne kadar ciddidir?

Bağlantınız varsa, belirli bir yapı ve formatta mesaj göndermek için kendi protokollerinizi (zor bir görev!) Tanımlamanız gerekmesine rağmen bir mesaj kuyruğuyla gidin.

Bakımla ilgili sorun genellikle istemci ve sunucunun ayrı ayrı inşa edilmesidir, bu nedenle her iki ucu da aynı mesaj tanımlarını kullanarak tutmaya dikkat etmelisiniz, ancak yeterince organize değilseniz, sadece REST'inizde kullanacağınız aynı XML'yi kullanın hizmet.

İnternet üzerinden bağlantı sorunları yaşıyorsanız, yalnızca bağlantı noktası 80 ve http ve 'tek yönlü' comms ile REST stil sistemi muhtemelen en iyisidir. Geri arama verisi göndermek ve göndermek için bir websocket alın, ancak genellikle sisteminizi istemci / sunucu olarak tasarlayın. Bağlanabilirlik özelliğine sahipseniz, mesajlaşma sistemleri mükemmeldir.

Bir mesajlaşma sistemi için ZeroMQ ile giderdim , hataya dayanıklı olanlar da dahil olmak üzere her türlü senaryoyu bükecek şekilde yapılandırılabilir. Yine de http üzerinde çalıştığından emin değilim .

Autobahn, yapmaya çalıştığınız şeye iyi uyuyor gibi görünüyor. Başka araçlar da var. Check out , Windows Azure Service Bus (Java, .NET, PHP, Python, NodeJS ve Ruby için istemci çerçeveler vardır).

Yerleşik dinlenme mesajları yararlı olsa da. Uygulamanızın temel CRUD işlemlerini aşacağını göreceksiniz. Örneğin başvurunuz bir bankacılık sistemi olsaydı. Onun yerine

Güncelleme İşlemi 54321 Bakiye = Bakiye - 20.00 Güncelleme İşlemi 98765 Bakiye = Bakiye + 20.00

Muhtemelen aşağıdaki gibi tek bir mesaj istersiniz

20.00 hesap 54321 hesap 98765 transfer

Bu engeli daha sonra değil REST ile keşfetmeniz en iyisidir. Uygulamanız içinde mesajlaşma için nasıl daha zengin bir model oluşturulacağını tartışan Greg Young Etkinlik Merkezine göz atın.