Salta ai contenuti

I protocolli supportati

In Restorm un protocollo non è una modalità degradata di HTTP: ciascuno ha il proprio editor, la propria esecuzione e la propria resa della risposta. Lo stesso progetto può quindi contenere una chiamata REST, una sottoscrizione MQTT e un consumer Kafka uno accanto all’altro.

Tutti i protocolli di esecuzione sono inclusi nell’edizione Community, senza limiti.

ProtocolloA che cosa serveModalità server
HTTPREST e qualsiasi chiamata HTTP✔
GraphQLQuery, mutation, subscription✔
gRPCChiamate unarie e in streaming, gRPC-Web, Connect✔
SOAPServizi WSDL, buste XML✔
ODataInsiemi di entità, opzioni di query, $batch✔
JSON-RPCJSON-RPC 2.0, singolo o in batch—
tRPCProcedure query e mutation—
ProtocolloA che cosa serveModalità server
WebSocketConnessione bidirezionale grezza✔
Socket.IOEventi denominati Socket.IO✔
MQTTIoT — topic, QoS, ritenzione, testamento✔
SSEServer-Sent Events, in ricezione—
STOMPSTOMP su WebSocket—
AMQPRabbitMQ — pubblicare, consumare, ispezionare—
KafkaProdurre, consumare, ispezionare una partizione—
RedisPub/Sub e comandi—
  • Le {{variables}} vengono risolte in tutti i campi, compresi i campi propri del protocollo. Si veda Variabili inline.
  • La cronologia registra ogni esecuzione, qualunque sia il protocollo. Si veda Cronologia delle richieste.
  • Gli snippet di codice vengono generati per ciascun protocollo, nei linguaggi pertinenti. Si veda Esportazione di codice.
  • Gli scenari sanno pilotare ogni protocollo, comprese le connessioni di lunga durata (connettere / inviare / chiudere). Si veda il catalogo delle azioni.
  • Il firewall intercetta tutte le chiamate in uscita, qualunque sia il trasporto. Si veda Firewall.

Per essere chiari sui limiti: Restorm non esegue Thrift (la sua importazione è documentale), né AMQP 1.0 (è implementato soltanto AMQP 0-9-1 / RabbitMQ), né NATS.