Comment concevoir une passerelle HTTP RESTful pour un protocole nécessitant des connexions permanentes?

Question

Je travaille avec un protocole client/serveur persistant et j'ai besoin de concevoir une passerelle RESTful. Je n'ai pas beaucoup d'expérience dans la conception d'interfaces REST et je ne comprends pas comment gérer (de façon RESTful) les identifiants de session nécessaires pour maintenir les connexions persistantes sur le serveur et comment représenter l'état du serveur en tant que ressources.

Je pose cette question parce que je ne veux pas finir avec un résultat RPC-ish qui semble "RESTful".

Contexte spécifique au problème: Je souhaite améliorer la passerelle ZooKeeper REST existante pour prendre en charge les noeuds et les montres éphémères. Un noeud éphémère existe lorsque le client est connecté au serveur.

Merci.

Answer 1

La façon dont j'ai fait cela dans le passé suit un modèle de "ticket" ou de "ticket". Le service REST accepte les demandes d'une ressource (un nom de rapport, un znode, etc.) et renvoie un ticket. Ce ticket (généralement un UUID ou quelque chose de similaire) peut être utilisé pour représenter une session. Les demandes suivantes utilisent ce ticket pour vérifier l'état de leurs demandes. Pour assurer l'expirey des billets, l'un des deux cas se produit; Vous pouvez expirer vos tickets ou, à la réception d'un résultat, le client doit fournir un ACK (accusé de réception) au service.

ex.

Demande: GET/Zookeeper/znode/éphémère/foo Réponse: 1234-1234-1234-1234

Demande: GET/Zookeeper/état/1234-1234-1234-1234 Réponse: TRAVAIL (ou INDISPONIBLE ou BLOQUE ou NOTREADY ou ECHEC ...)

Demande: GET/Zookeeper/état/1234-1234-1234-1234 Réponse: ACQUIS (ou disponibles ou sur OK ou SUCCESS ou une valeur (s) ...)

Demande: GET/zookeeper/acquitteur/1234-1234-1234-1234 Réponse: OK (ou BILLET UNKNOWN, etc.)

messages gérabilité intéressants:

Demande: GET/zookeeper/sessions (ou/billets) Réponse: [1234, 5668, ...]

Demande : GET/zookeeper/kill/ Réponse: OK (ou UNKNOWN ou FAILED ...)

Cela a très bien fonctionné. Cela signifie, cependant, le service REST est dynamique, ce qui rend les choses comme l'équilibrage de charge plus délicat. J'ai utilisé un protocole qui garantit qu'un ID de serveur est renvoyé avec chaque réponse et si le client reçoit un ID de serveur différent et un ticket INCONNU, vous supposez que le service auquel vous avez parlé est mort et recommencez. Ceci implique un équilibrage de la charge collante (c'est-à-dire que le round-robin ne fonctionnerait pas ici). Le service REST doit être multithread pour prendre en charge l'exécution de ces requêtes en parallèle et fournir un accès à une base de données de tickets (généralement en mémoire, structure de données de hachage synchronisée) ainsi qu'un thread de session/timeout de ticket.

Espérons que cela aide.