Przejdź do głównej zawartości

Obsługiwane protokoły

W aplikacji Restorm protokół nie jest okrojonym trybem HTTP: każdy ma własny edytor, własny sposób wykonania i własny sposób prezentacji odpowiedzi. Ten sam projekt może więc zawierać obok siebie wywołanie REST, subskrypcję MQTT i konsumenta Kafka.

Wszystkie protokoły wykonawcze wchodzą w skład edycji Community, bez żadnych ograniczeń.

ProtokółDo czego służyTryb serwera
HTTPREST i każde wywołanie HTTP
GraphQLZapytania, mutacje, subskrypcje
gRPCWywołania unarne i strumieniowe, gRPC-Web, Connect
SOAPUsługi WSDL, koperty XML
ODataZestawy encji, opcje zapytań, $batch
JSON-RPCJSON-RPC 2.0, pojedynczo lub wsadowo
tRPCProcedury query i mutation
ProtokółDo czego służyTryb serwera
WebSocketSurowe połączenie dwukierunkowe
Socket.IONazwane zdarzenia Socket.IO
MQTTIoT — tematy, QoS, retencja, testament
SSEServer-Sent Events, w trybie odbioru
STOMPSTOMP na WebSocket
AMQPRabbitMQ — publikowanie, konsumowanie, inspekcja
KafkaProdukowanie, konsumowanie, inspekcja partycji
RedisPub/Sub i polecenia
  • {{variables}} są rozwiązywane we wszystkich polach, także w polach specyficznych dla danego protokołu. Zob. Zmienne inline.
  • Historia rejestruje każde wykonanie, niezależnie od protokołu. Zob. Historia żądań.
  • Fragmenty kodu są generowane dla każdego protokołu, w odpowiednich dla niego językach. Zob. Eksport kodu.
  • Scenariusze potrafią sterować każdym protokołem, w tym połączeniami długotrwałymi (połączenie / wysłanie / zamknięcie). Zob. Katalog akcji.
  • Zapora przechwytuje wszystkie wywołania wychodzące, niezależnie od transportu. Zob. Zapora.

Dla jasności co do ograniczeń: Restorm nie wykonuje Thrift (jego import ma charakter wyłącznie dokumentacyjny), ani AMQP 1.0 (zaimplementowany jest tylko AMQP 0-9-1 / RabbitMQ), ani NATS.