Aller au contenu

Les protocoles pris en charge

Dans Restorm, un protocole n’est pas un mode dégradé de HTTP : chacun a son propre éditeur, sa propre exécution et son propre rendu de réponse. Le même projet peut donc contenir un appel REST, un abonnement MQTT et un consommateur Kafka côte à côte.

Tous les protocoles d’exécution sont inclus dans l’édition Community, sans limite.

ProtocolePour quoi faireMode serveur
HTTPREST et tout appel HTTP
GraphQLRequêtes, mutations, abonnements
gRPCAppels unaires et en flux, gRPC-Web, Connect
SOAPServices WSDL, enveloppes XML
ODataJeux d’entités, options de requête, $batch
JSON-RPCJSON-RPC 2.0, unitaire ou par lot
tRPCProcédures query et mutation
ProtocolePour quoi faireMode serveur
WebSocketConnexion bidirectionnelle brute
Socket.IOÉvénements nommés Socket.IO
MQTTIoT — sujets, QoS, rétention, testament
SSEServer-Sent Events, en réception
STOMPSTOMP sur WebSocket
AMQPRabbitMQ — publier, consommer, inspecter
KafkaProduire, consommer, inspecter une partition
RedisPub/Sub et commandes
  • Les {{variables}} sont résolues dans tous les champs, y compris les champs propres au protocole. Voir Variables en ligne.
  • L’historique enregistre chaque exécution, quel que soit le protocole. Voir Historique des requêtes.
  • Les extraits de code sont générés pour chaque protocole, dans les langages pertinents. Voir Export de code.
  • Les scénarios savent piloter chaque protocole, y compris les connexions longue durée (connecter / envoyer / fermer). Voir Catalogue des actions.
  • Le pare-feu intercepte tous les appels sortants, quel que soit le transport. Voir Pare-feu.

Pour être clair sur les limites : Restorm n’exécute pas Thrift (son import est documentaire), ni AMQP 1.0 (seul AMQP 0-9-1 / RabbitMQ est implémenté), ni NATS.