REST czy kolejka komunikatów w heterogenicznym systemie wielowarstwowym?

Projektuję interfejs API REST dla trójwarstwowego systemu, takiego jak: Client application-> Front-end API cloud server-> user's home API server (Home).

Homejest urządzeniem domowym i ma utrzymywać połączenie Front-endprzez Websocket lub długą ankietę (jest to pierwsze miejsce, w którym naruszamy REST. Później staje się jeszcze gorzej) . Front-endgłównie tuneluje Clientżądania Homepołączenia i obsługuje niektóre połączenia. Czasami Homewysyła powiadomienia do Client.

Front-endi Homemają w zasadzie ten sam interfejs API; Clientmoże łączyć się Homebezpośrednio przez sieć LAN. W takim przypadku Homemusi zarejestrować niektóre Clientdziałania na Front-endsobie.

Plusy dla REST w tym systemie to:

• REST jest czytelny dla człowieka;
• REST ma dobrze zdefiniowane odwzorowanie czasowników (takich jak CRUD), rzeczowników i kodów odpowiedzi na obiekty protokołu;
• Działa przez HTTP i przekazuje wszystkie możliwe proxy;

Kontrole REST to:

• Potrzebujemy nie tylko stylu komunikacji żądanie-odpowiedź, ale także subskrypcji publikowania;
• Kody błędów HTTP mogą być niewystarczające do obsługi błędów komunikacji trójwarstwowej; Front-endmoże powrócić 202 Accepteddo jakiegoś wywołania asynchronicznego, aby dowiedzieć się, że konieczne Homepołączenie zostało zerwane i powinno być 503;
• Homemusi wysłać wiadomości do Client. Clientbędzie musiał odpytać Front-endlub utrzymać połączenie.

Rozważamy WAMP / Autobahn przez Websocket, aby uzyskać funkcjonalność publikowania / subskrybowania, kiedy uderzyło mnie, że już wygląda jak kolejka wiadomości.

Czy warto oceniać rodzaj kolejki przesyłania komunikatów jako transportu?

Wygląda na to, że kontrole kolejki wiadomości to:

• Będę musiał sam zdefiniować czasowniki CRUD i kody błędów na poziomie komunikatu.
• Przeczytałem coś o „wyższych kosztach utrzymania”, ale co to znaczy?

jak poważne są te względy?

Jeśli masz łączność, idź z kolejką komunikatów - chociaż musisz zdefiniować własne protokoły (trudne zadanie!), Aby wysyłać wiadomości o określonej strukturze i formacie.

Problem z konserwacją polega na tym, że zazwyczaj klient i serwer są budowane osobno, więc musisz zachować ostrożność, aby zachować obie strony przy użyciu tych samych definicji komunikatów, ale jeśli nie jesteś wystarczająco zorganizowany, po prostu użyj tego samego kodu XML, którego użyłbyś w REST usługa.

Jeśli masz problemy z łącznością przez Internet, tylko z portem 80 i http oraz komunikacjami „jednokierunkowymi”, prawdopodobnie styl w stylu REST jest prawdopodobnie najlepszy. Wysyłaj i odpytuj lub uzyskaj gniazdo sieciowe na dane zwrotne, ale ogólnie architekt systemu powinien być klientem / serwerem. Jeśli masz możliwość uzyskania łączności, to systemy wiadomości są świetne.

Pójdę z ZeroMQ dla systemu komunikacyjnego, jego konfigurowalny wystarczy przekręcić w rozmaitych sytuacjach, także odporny na uszkodzenia. Nie jestem jednak pewien, czy działa na http .

Wygląda na to, że Autobahn ładnie pasuje do tego, co próbujesz zrobić. Dostępne są również inne narzędzia. Sprawdź usługę Windows Azure Service Bus (która ma struktury klienta dla Java, .NET, PHP, Python, NodeJS i Ruby).

Podczas gdy wbudowane komunikaty odpoczynku są przydatne. Przekonasz się, że Twoja aplikacja przerośnie podstawowe operacje CRUD. Na przykład, jeśli Twoja aplikacja była systemem bankowym. Zamiast

Aktualizacja Acct 54321 Saldo = Saldo - 20,00 Aktualizacja Acct 98765 Saldo = Saldo + 20,00

Prawdopodobnie chciałbyś mieć jedną wiadomość

Przenieś 20,00 z konta 54321 na konto 98765

Najlepiej jest, gdy odkryjesz tę przeszkodę w REST teraz niż później. Sprawdź Greg Young's Event Centric, który omawia sposób tworzenia bogatszego modelu przesyłania wiadomości w aplikacji.