REST ou une file d'attente de messages dans un système hétérogène à plusieurs niveaux?


9

Je conçois une API REST pour un système à trois niveaux comme: Client application-> Front-end API cloud server-> user's home API server (Home).

Homeest un appareil domestique, et est censé maintenir la connexion Front-endvia Websocket ou un long sondage (c'est le premier endroit où nous violons REST. Il empire encore plus tard) . Front-endtunnelise principalement les Clientdemandes de Homeconnexion et gère certains appels lui-même. Envoie parfois Homedes notifications à Client.

Front-endet Homeont essentiellement la même API; Clientpeut se connecter Homedirectement sur LAN. Dans ce cas, Homedoit enregistrer certaines Clientactions sur Front-endlui - même.

Les avantages de REST dans ce système sont:

  • REST est lisible par l'homme;
  • REST a un mappage bien défini des verbes (comme CRUD), des noms et des codes de réponse aux objets de protocole;
  • Il fonctionne sur HTTP et passe tous les proxy possibles;

Les contras REST sont:

  • Nous avons besoin non seulement d'un style de communication demande-réponse, mais également d'un abonnement à la publication;
  • Les codes d'erreur HTTP peuvent être insuffisants pour gérer les erreurs de communication à trois niveaux; Front-endpeut revenir 202 Acceptedà un appel asynchrone uniquement pour découvrir que la Homeconnexion nécessaire est rompue et qu'il aurait dû y en avoir 503;
  • Homedoit envoyer des messages à Client. Clientdevra interroger Front-endou maintenir une connexion.

Nous envisageons WAMP / Autobahn sur Websocket pour obtenir la fonctionnalité de publication / abonnement, quand il m'a semblé que cela ressemblait déjà à une file d'attente de messages.

Vaut-il la peine d'évaluer une sorte de file d'attente de messagerie comme moyen de transport?

On dirait que les contras de la file d'attente de messages sont:

  • Je vais devoir définir moi-même les verbes CRUD et les codes d'erreur au niveau du message.
  • J'ai lu quelque chose sur "des coûts de maintenance plus élevés", mais qu'est-ce que cela signifie?

Quelle est la gravité de ces considérations?


1
Pourquoi avez-vous un serveur cloud dans le mélange? On dirait que tout ce qu'il fait est rediriger, ce qui me fait penser qu'il devrait vraisemblablement vivre sur la même machine que le serveur domestique ...
Jimmy Hoffa

3
lorsque vous analysez les files d'attente de messages, notez que la plupart d'entre elles sont optimisées pour les réseaux locaux privés: faible latence, clients contrôlés, réseau protégé, etc., exposer la file d'attente à Internet peut être un énorme problème de sécurité.
Javier

@Jimmy Hoffapoint valable, merci. C'est vrai, mais pas complètement. Il s'agit d'une base de données, d'un stockage, etc. communs. @Javiermerci, c'est une bonne partie d'une réponse.
Victor Sergienko

Le serveur domestique est-il destiné à être exécuté au domicile d'un utilisateur et au front-end dans le cloud? Le domicile se connecte au front-end et le client envoie des messages au domicile via le front-end. Si je comprends bien votre conception, je peux donner une réponse divine.
Michael Brown du

@Mike Brownexactement. Je vous en prie.
Victor Sergienko

Réponses:


5

Si vous avez la connectivité, optez pour une file d'attente de messages - même si vous devez définir vos propres protocoles (ce qui n'est pas une tâche difficile!) Pour envoyer des messages d'une structure et d'un format particuliers.

Le problème avec la maintenance est que généralement le client et le serveur sont construits séparément, vous devez donc faire attention à garder les deux extrémités en utilisant les mêmes définitions de message, mais si vous n'êtes pas assez organisé, utilisez simplement le même XML que vous utiliseriez dans votre REST un service.

Si vous avez des problèmes de connectivité sur Internet, avec les ports 80 et http uniquement et les communications «unidirectionnelles», un système de style REST est probablement le meilleur. Envoyez et interrogez, ou lancez une websocket pour les données de rappel, mais en règle générale, votre système doit être client / serveur. Si vous avez la possibilité d'obtenir la connectivité, les systèmes de messagerie sont parfaits.

J'irais avec ZeroMQ pour un système de messagerie, son assez configurable pour se tordre dans toutes sortes de scénarios, y compris ceux tolérants aux pannes. Je ne suis pas sûr que cela fonctionne sur http cependant.


Merci. Ce que j'ai trouvé après un @Javiercommentaire: ØMQ ne semble pas prendre en charge le cryptage lui-même atm: zeromq.org/area:faq#toc8 bien que RabbitMQ le fasse: rabbitmq.com/ssl.html
Victor Sergienko

Je ne sais pas si j'ai la connectivité. Homeest un appareil domestique et Clientest un smartphone via Wi-Fi ou 3G. Une grande partie de la question est mon ignorance des méthodes de traversée NAT.
Victor Sergienko

5

Il semble qu'Autobahn cadre bien avec ce que vous essayez de faire. Il existe également d'autres outils. Découvrez le bus de service Windows Azure (qui a des cadres clients pour Java, .NET, PHP, Python, NodeJS et Ruby).

Alors que les messages de repos intégrés sont utiles. Vous constaterez que votre application dépassera les opérations CRUD de base. Par exemple, si votre application était un système bancaire. Au lieu de

Mettre à jour Acct 54321 Balance = Balance - 20.00 Mettre à jour Acct 98765 Balance = Balance + 20.00

Vous voudriez probablement un seul message comme

Transférez 20,00 du compte 54321 vers le compte 98765

Il vaut mieux que vous découvriez cet obstacle avec REST maintenant plutôt que plus tard. Consultez Event Centric de Greg Young qui explique comment créer un modèle plus riche pour la messagerie au sein de votre application.


Merci beaucoup. En effet, nous pourrions devenir trop grands pour CRUD, mais pas très bientôt, notre domaine est assez simple maintenant. BTW le livre n'est pas encore publié, essayant de trouver des matériaux dans le blog de Greg ... Je pense que c'est bien, je n'ai pas besoin d'utiliser la technologie Microsoft pour ça.
Victor Sergienko

Attendez que son livre ne soit toujours pas sorti ... il en parle depuis si longtemps ... sonne comme un autre auteur technique que je connais. : ">
Michael Brown

1
Pour mémoire, l'approche REST serait d'avoir une ressource de transfert que vous créez. Ou même une demande de transfert qui peut réussir ou non. REST devient délicat dans certains cas, mais ce n'est pas l'un d'entre eux.
Jacek Gorgoń
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.