Laden...

Rückkanal in Rest API

Erstellt von jogibear9988 vor einem Jahr Letzter Beitrag vor einem Jahr 1.144 Views
J
jogibear9988 Themenstarter:in
641 Beiträge seit 2007
vor einem Jahr
Rückkanal in Rest API

Wir haben für unser WMS System als Schnittstelle eine Http/Rest Schnittstelle mit Swagger Interface.
Nun ist für mich die Frage, was ist die beste Möglichkeit für einen Rückkanal.

Im Moment wurde es so entwickelt, es gab einen GET Aufruf mit dem man die Antworten abgerufen hat, und diese hat im Header auch noch gesagt ob es weitere gibt.
Und Wenn keine Antwort vorlag, hat der Aufruf so lange blockiert bis eine weitere eingetragen wurde (Long Polling).

Was ist da gerade so state of the art?

cSharp Projekte : https://github.com/jogibear9988

16.806 Beiträge seit 2008
vor einem Jahr

a) Metainformationen über den Json Body, nicht den Header
b) WebSockets mit Push; Long Polling ist nur ein technischer Fallback
c) es darf niemals irgendwas blockieren

PS: Du meinst vermutlich eher eine "Http API" statt REST per Definition.
REST hat klare, strikte Regeln, die Deiner Beschreibung (wie blocken etc..) widersprechen.
https://dotnet.rest/

J
jogibear9988 Themenstarter:in
641 Beiträge seit 2007
vor einem Jahr

D.h. die API aber trotzdem Per PUT/GET/POST?

Und per Websocket nur den Antwortkanal?

Ich meine wenn ich per GET die Url für eine Antwort auslese, bleibt der Request so lange offen bis entweder eine Antwort kommt oder die Anfrage einen Timeout hat

cSharp Projekte : https://github.com/jogibear9988

J
jogibear9988 Themenstarter:in
641 Beiträge seit 2007
vor einem Jahr

Und wieso MetaInformationen nicht in den Header?

Dann muss Ich mein Json Antworktobjekt ja nochmals in ein Zusätzliches mit Metainformationen packen

cSharp Projekte : https://github.com/jogibear9988

J
jogibear9988 Themenstarter:in
641 Beiträge seit 2007
vor einem Jahr

Nochwas, was ist eig. besser, moderner, besser gepflegt.

NSwag oder Swashbuckle?

cSharp Projekte : https://github.com/jogibear9988

16.806 Beiträge seit 2008
vor einem Jahr

3 Beiträge in 4 Minuten. Muss das sein? Auch Du hast nen Edit Button, der 30 Minuten funktioniert.

Ich meine wenn ich per GET die Url für eine Antwort auslese, bleibt der Request so lange offen bis entweder eine Antwort kommt oder die Anfrage einen Timeout hat

Soll man niemals tun, weil Du damit Systemressourcen allokierst - sowohl für den Client wie auch für den Server.
Pure Verschwendung, Flow-fragwürdig und potentiell ein Angriffsvektor (im Sinne der Skalierung).
Dazu weit weg von jeglichem Standard.

D.h. die API aber trotzdem Per PUT/GET/POST?

Die Frage steht in welchem Zusammenhang?
Eine REST API ist immer eine HTTP API, aber eine HTTP API ist nicht immer eine REST API.
REST ist ein Paradigma, ein Vorgehensmodell mit Regeln. Erfüllst Du REST nicht, dann hast immer noch eine HTTP API mit allen HTTP Möglichkeiten.
Schau Dir dazu die Grundlagen von HTTP APIs und REST an, darunter zB das Maturity Model von Fowler.

Und wieso MetaInformationen nicht in den Header?

Auch hier verweis ich gern auf HTTP Grundlagen 🙂
Meta Informationen zum Inhalt sollten teil des Bodys sein.
Meta Informationen zur Infrastruktur sollten teil des Headers sein.

Nur aus Rückwärts-Kompatibilitäten macht man manchmal Workarounds, dass man zB Meta-Informationen des Inhalts in den Headern hat.

Dann muss Ich mein Json Antworktobjekt ja nochmals in ein Zusätzliches mit Metainformationen packen

Korrekt. Sollte Teil Deiner API Modellstruktur sein.

Meine APIs haben als Basis immer folgende ohne darauf basierende Modelle:


// https://github.com/BenjaminAbt/AspNetCoreEnterprisePlatform/blob/3ff093615681e56a3381cf7ba5530ec9dee5e144/src/HttpApi.Sdk/Models/CollectionResult.cs#LL7-L17C2
public class CollectionResult<T> : BaseResult
{
    public CollectionResult(List<T> data, CollectionResultMetadata metadata)
    {
        Data = data;
        Metadata = metadata;
    }

    public List<T> Data { get; set; }
    public CollectionResultMetadata Metadata { get; set; }
}


// https://github.com/BenjaminAbt/AspNetCoreEnterprisePlatform/blob/3ff093615681e56a3381cf7ba5530ec9dee5e144/src/HttpApi.Sdk/Models/ObjectResult.cs#L5
public class ObjectResult<T> : BaseResult
{
    public ObjectResult(T? data, ObjectResultMetadata metadata)
    {
        Data = data;
        Metadata = metadata;
    }

    public T? Data { get; set; }
    public ObjectResultMetadata Metadata { get; set; }
}

Die Uhrzeit des Zustands eines Modells mitzuschicken gilt auch als Best Practise, damit der Client weiß, wie aktuell eine Antwort ist (zB aufgrund von Caching).

NSwag oder Swashbuckle?

Beides. Vergleich die Funktionalitäten, was Du brauchst.

J
jogibear9988 Themenstarter:in
641 Beiträge seit 2007
vor einem Jahr

Und wie gibst du in ObjectResult oder CollectionResult den Typ mit?
Also wenn es nicht als Antwort auf ein POST/GET kommt sondern über den Websocket Kanal?
Ich muss ja dann wissen was es für ein Typ ist.

cSharp Projekte : https://github.com/jogibear9988

16.806 Beiträge seit 2008
vor einem Jahr

Ist doch ein normales, generisches Modell. Kannst also nutzen wie alle generischen Modelle.
Meine Antwort hat nen Link zum GitHub Repo. Kann man die Verwendung problemlos anschauen.

Also wenn es nicht als Antwort auf ein POST/GET kommt sondern über den Websocket Kanal?

Wir reden die ganze Zeit von HTTP Antworten mit Body und Headern.
Wo kommt nun der WebSocket her, und wieso wird das mit dem HTTP Thema und dem generischen Modell vermischt?

Die Aussage von WebSocket war einzig und allein, dass man keine Anfragen blockiert "bis es eine Antwort gibt".
Das war Deine Frage ("state of the art") im ersten Post.

J
jogibear9988 Themenstarter:in
641 Beiträge seit 2007
vor einem Jahr

Nochmals,
wir haben ein WMS, welches eine Standard HTTP (ob wir nun genau Rest haben oder nicht) Schnittstelle bietet. Dadurch kann das überlagerte System bei uns Aufträge einstellen, Materialien anlegen usw.
Das reicht auch für viele Kunden.

Viele brauchen aber auch einen Rückkanal wenn z.B. ein Auftrag fertig gestellt wurde.
Wie würdet Ihr diesen bauen?
Ein Kunde z.b. will jetzt das wir nun wiederum seine Rest API aufrufen. Dies passt aber nicht zu unserem Standard Interface da dies bei jedem Kunden anders wäre
Bei anderen haben wir es im Moment so, das sie ständig per Get Pollen ob es neue Antworten gibt. (Das haben wir in unserer Standard HTPP Schnittstelle so drin, gefällt uns aber eben nicht wirklich.

Daher war die Frage wie würde man den Rückkanal implementieren.

Wir brauchen kein LoadBalancing oder ähnlichen Schnickschnack, an der Schnittstelle hängt maximal 1 Client, also High Perfomance Szenarien brauchen wir nicht supporten.
Wichtig ist uns das wir es Standardisiert haben, das wir bei klein Projekten dem Kunden diese Schnittstelle bieten können, aber ohne Anpassungen.

cSharp Projekte : https://github.com/jogibear9988

2.078 Beiträge seit 2012
vor einem Jahr

Wenn der Kunde eine eigene API hat, die ihr aufrufen sollt, dann lass doch euren Server einen pro Kunde konfigurierbaren Endpunkt aufrufen. Könnte man auch weiter spinnen und Platzhalter erfinden, damit ihr Daten aus dem Ergebnis in die URL bzw. den Body schreiben könnt.
So ein generisches Ding baut Ihr dann einmal und könnt es für jeden Kunden mit einer solchen API anpassen.

Wenn der Kunde keine API hat, dann bietet einen Long-Polling-Endpunkt an, lebt dann aber mit den genannten Nachteilen.
Oder ihr lasst den Kunden alle paar Sekunden nach dem Ergebnis fragen, das ist dann auch weniger Entwicklungsaufwand.

J
jogibear9988 Themenstarter:in
641 Beiträge seit 2007
vor einem Jahr

Ja, da wollte Ich eben wissen, was ist state of the art.
Wir machen eben gerade die HTTP/REST Schnittstelle neu, mit Swagger UI, Automatischer Doku usw... Weil das vorher was wild zusammengestriktes war. Eine Schnittstelle die HTPP oder TCP oder Dateibasiert konnte, nichts gut, schlecht dokumentiert usw...

Mir geht es halt auch um die Dokumentation, mit Swagger bekomme ich eine schöne Doku und Testumgebung für die eine Richtung sofort.

cSharp Projekte : https://github.com/jogibear9988

16.806 Beiträge seit 2008
vor einem Jahr

Nochmals,
wir haben ein WMS, welches eine Standard HTTP (ob wir nun genau Rest haben oder nicht) Schnittstelle bietet. Dadurch kann das überlagerte System bei uns Aufträge einstellen, Materialien anlegen usw.
Das reicht auch für viele Kunden.

Viele brauchen aber auch einen Rückkanal wenn z.B. ein Auftrag fertig gestellt wurde.

Auch gerne nochmal. Du hast zwei Dinge.

Du hast eine HTTP API, die nach den Regeln von HTTP spielt (keines Request Response) - ergo musst auch Du hier nach HTTP Regeln spielen.

Hier hatten wir von Metadaten gesprochen, wie diese bei einem Hypermedia-Endpunkt eigentlich geliefert werden sollten: als Body.
Du hast Dir Deine Hypermedia-Infos (das ist der Begriff für Deine Metadaten) selbst gebastelt, statt Dich daran zu orientieren, wie es gedacht ist.
Kann man machen, wenn man es bewusst macht.

Du willst eine zusätzliche Lösung für Events aka "Wenn es etwas neues gibt" - und zwar State of the Art.

Viele brauchen aber auch einen Rückkanal wenn z.B. ein Auftrag fertig gestellt wurde.
Wie würdet Ihr diesen bauen?

Auch hier gerne nochmal: mit einer Event-basierten Lösung wie WebSockets. Das ist State of the Art.
Du kannst auch andere Lösungen in Betracht ziehen, wie WebHooks oder Long Polling - aber die Frage war halt auch nur "was ist state of the art".
Diese Antwort beeinflusst aber nicht meine Antwort, wie man einen HTTP API Return mit Metadaten macht.


Es ist immer schlecht 2 Fragen in einem Thread zu haben, wenn man die Antworten vermischt.
Du musst Dich auch entscheiden, was für Dich praktikabel ist und was "state of the art" ist. Besonders letzteres ist nicht immer für den kleinsten Aufwand und die kleinste Umgebung die beste Lösung.
Die Frage ist daher in den aller meisten Fällen - wie hier - die Basis, dass es in die falsche Richtung geht.

Du musst für Dich die beste Lösung finden; nicht die beste Lösung von anderen kopieren.


Mir geht es halt auch um die Dokumentation, mit Swagger bekomme ich eine schöne Doku und Testumgebung für die eine Richtung sofort.

Swagger ist eigentlich ein Architekturkonzept.
Man entwickelt einen Swagger - bzw OpenAPI wie es seit vielen Jahren korrekterweise heisst - Dokument, das einen Schnittstellenvertrag darstellt.
Das Server und der/die Client/s können dann parallel diesen Contract implementieren, ohne auf das andere "Team" warten zu müssen. Denn gerade aus dem Frontend hieß es oft "das Backend ist nicht fertig wir können nichts testen". Dank OpenAPI Contract ist diese Ausrede Geschichte.

Daher entwickelt man eigentlich einen OpenAPI Contract bevor man eine einzige Zeile Code schreibt, sodass man HTTP oder eben auch REST Prinzipien >planbar< in den Contract umsetzen kann, und nicht dass die API Struktur "zufällig" erzeugt wird, wie Leute morgens so ticken.
Ja, man kann sich auch das Zeug alles generieren lassen, wenn man faul ist (gehöre ich bei kleineren Apps auch dazu) - aber das ist nicht die Idee von OpenAPI.

Ein OpenAPI Contract ist schließlich auch ein Element für das Unit- bzw. Integration Testing.

2.078 Beiträge seit 2012
vor einem Jahr

Du schreibst, dass Ihr mehrere Kunden habt und die z.B. über den Auftragsstatus informiert werden wollen.
Mit der Anforderung würde ich nicht nach dem State of the Art suchen, sondern nach einer möglichst einfachen, möglichst flexiblen und gut erweiterbaren Lösung.
Komplexere Systeme würde ich erst dann entwickeln, wenn ein Kunde danach fragt und der (bzw. der zu erwartende Umsatz) auch den Entwicklungsaufwand rechtfertigt, sonst verzettelst Du dich ganz schnell und am Ende ist kein Kunde wirklich zufrieden.

Ich bin selbst kein Experte auf dem Gebiet, aber ich habe an ein paar Projekten mit einer solchen bi-direktionalen Kommunikation mit gearbeitet und ich bezweifle einfach mal, dass jeder Kunde, ein groß aufgestelltes und top aktuelles System hat.
Wenn Du stattdessen aber einen einfachen Endpunkt anbietest, über den jeder mit ein paar grundlegenden Programmierkenntnissen nach einem aktuellen Status fragen kann, erreichst Du damit vermutlich sehr viel mehr.
Oder umgekehrt, wenn Du ein flexibles System anbietest, über das Du quasi jede HTTP-API ansteuern kannst, erschlägst Du jeden Kunden, der einen API-Call haben möchte.
Natürlich erreichst Du damit keine 100%, aber Du erreichst sehr viele.

Mir schwebt da gerade folgendes Konzept vor:

  • Kunde schickt euch irgendwelche Daten, die im Hintergrund einen Prozess anstoßen
  • Kunde bekommt eine Prozess-ID zurück
  • Kunde schickt alle paar Sekunden die Prozess-ID an einen Status-Endpunkt, der dann mit Queued, Running, Completed oder Failed und ggf. mehr Daten antwortet.

Oder, wenn der Kunde einen Endpunkt hat:

  • Ihr und der Kunde einigt euch vorher über den Endpunkt und welche Daten dort mitgegeben werden sollen
  • Kunde schickt euch irgendwelche Daten, die im Hintergrund einen Prozess anstoßen
  • Nach Ende des Prozesses wird ein JSON/XML/Text-Dokument mit Platzhaltern aus den Daten und dem Ergebnis gefüllt und an den Endpunkt verschickt

Somit hättet Ihr vermutlich die Mehrheit der Kunden unter einen Hut gebracht.
Viel spannender ist, wie das Backend hinter der API aussieht, denn das sollte möglichst einfach um ein neues Konzept erweitert werden können, damit dann auch WebSockets möglich sind.
Doch ich würde auf keinen Fall nur auf eine Technologie setzen, sonst müsst Ihr noch Kunden ablehnen, weil Ihr die Kommunikation nicht könnt.

Wie sinnvoll mein Konzept ist, muss Abt beurteilen, der hat da mehr Erfahrung als ich 😄

J
jogibear9988 Themenstarter:in
641 Beiträge seit 2007
vor einem Jahr

Mir geht es halt hauptsächlich darum das wir die API in C# Entwickeln können, und das ganze auch zur Doku verwenden können.
Ja normalerweise sollten wir die API schön planen und dann danach entwickeln, aber so läufts bei uns leider meist nicht.

Hab jetzt noch das gefunden: https://github.com/OAI/OpenAPI-Specification/issues/55 Scheint es gibt mehrere die Swagger gerne auch zur doku von websockets hätten.

Aber das hört sich für mich am interessantesten an: https://github.com/OAI/OpenAPI-Specification/issues/396
Server Sent Events. Sind diese auch in Swashbuckle oder NSwag integriert?

=> update, hab das völlig falsch gelesen, dachte Server Sent Events wären in Swagger, sind es wohl aber nicht.

Nochmal Editiert:

Aber swagger erlaubt wohl Callbacks:
https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.1.0.md#callbackObject
https://swagger.io/docs/specification/callbacks/

cSharp Projekte : https://github.com/jogibear9988

16.806 Beiträge seit 2008
vor einem Jahr

Hab jetzt noch das gefunden:
>
Scheint es gibt mehrere die Swagger gerne auch zur doku von websockets hätten.

Das ist nicht der Sinn von OpenAPI - und ich hoffe, dass das niemals in OpenAPI landen wird.

Server Sent Events. Sind diese auch in Swashbuckle oder NSwag integriert?

Auch das ist nicht das Ziel von OpenAPI. WebSockets gelten auch als Nachfolger der SSE, weswegen das insgesamt unwahrscheinlich ist.
Vor allem sind SSE für Browser entwickelt worden, nicht für generische, HTTP-basierte Clients.

Aber swagger erlaubt wohl Callbacks:

OpenAPI - nicht Swagger. Swagger ist ein Unternehmen. Dahinter steckt SmartBear Software.
Swagger bietet Toolings für OpenAPI.

OpenAPI 3.0 hat Callbacks bekommen, OpenAPI 3.1 hat WebHooks bekommen.
Letzteres wurde Dir bereits ein paar Beiträge weiter oben als potentielle Möglichkeit genannt, wobei den WebHook Endpoint natürlich die Kunden unterstützen müssen.

WebHook sind sehr beliebt, einfach zu implementieren; aber sind nicht für sofortiges Real Time-Verhalten gedacht.
Womöglich passt das aber besser zu Deinem eher simple gewünschten Verhalten; WebSockets sind womöglich "zu oversized" für Deinen Fall.

J
jogibear9988 Themenstarter:in
641 Beiträge seit 2007
vor einem Jahr

WebHook sind sehr beliebt, einfach zu implementieren; aber sind nicht für sofortiges Real Time-Verhalten gedacht.
Womöglich passt das aber besser zu Deinem eher simple gewünschten Verhalten; WebSockets sind womöglich "zu oversized" für Deinen Fall.

Ja, die Performance der Antwort ist nicht wirklich relevant, nur das wir überhaupt benachrichtigen können.
Vlt. bieten wir dann ja auch beides an.
Was ist den der Unterschied zwischen Callbacks und Webhooks?

cSharp Projekte : https://github.com/jogibear9988

J
jogibear9988 Themenstarter:in
641 Beiträge seit 2007
vor einem Jahr

https://www.youtube.com/watch?v=et_2NBk4N4Y

Denke das hab ich gesucht.
Ich kann mit gRPC eine RPC Kommunikation machen, gleichzeitig aber auch eine Rest API zur verfügung stellen. ("Create RESTful services with gRPC JSON transcoding")

cSharp Projekte : https://github.com/jogibear9988

16.806 Beiträge seit 2008
vor einem Jahr

Denke Du vermischt oder missverstehst da was.

gRPC ist eine reine RPC Technologie, die mit REST und Co nichts zutun hat - weder im Schema noch in der Kommunikationsart.
Die einzige Gemeinsamkeit ist: es läuft über HTTP mit ASP.NET Core.

Das Transcoding bewirkt, dass der Proto-Contract als Json-Schnittstelle hinzugenommen wird.
Du hast dann zwei Endpunkte:

  • RPC over gRPC
  • RPC over Json
    Es ist also nichts anderes als ein Endpunkt-Generator. Das ist aber nicht gleichzeitig sondern parallel.
    Und einen "Rückkanal", wie Du es eigentlich beschrieben hast, gibts hier auch nicht.
    Deine Kunden müssten damit eine völlig neue Technologie implementieren, die besonders bei Firmen an der Firewall noch Probleme machen.
    Viele Corporate Firewalls unterstützen nämlich die dauerhaft offene Verbindung von gRPC nicht.
    Google Suche nach "grpc firewalls"

REST ist wie gesagt ein reines Paradigma, keine Technologie.
Wenn Du eine Json Schnittstelle durch RPC generierst, dann ist es eine Json RPC API und keine REST API.

Und ja, das steht auf den Folien auch falsch drauf. Gab auch schon Feedback dazu 😉

J
jogibear9988 Themenstarter:in
641 Beiträge seit 2007
vor einem Jahr

Hast du das Video angeschaut?

Es wird aus dem proto Contract gleichzeitig auch eine REST API erzeugt die du per Put/Get/Post.... nutzen kannst. Es wird aus dem Proto Contract eine OpenAPI definition erstellt, und auch eine SwaggerUI erzeugt. Das dies nicht für alle API Befehle geht, zumindest nicht in den der Server dann proaktiv was sendet ist mir klar.

Mir ist schon klar das der Kunde der Rest bzw. die HTTP API und nicht den GRPC Teil nutzt keinen Rückkanal hat.
Aber das ist okay für mich.

Firewallprobleme sind für mich auch kein Thema, unsere ganze Software läuft sowieso nur intern beim Kunden.

Wenn Du eine Json Schnittstelle durch RPC generierst, dann ist es eine Json RPC API und keine REST API.
Warum? Wenn die API die Rest Anforderungen erfüllt. (Representational State Transfer#Prinzipien)

cSharp Projekte : https://github.com/jogibear9988

16.806 Beiträge seit 2008
vor einem Jahr

Hast du das Video angeschaut?

Ja, und das was Du da beschreibst, passiert da nicht.

Es wird aus dem proto Contract gleichzeitig auch eine REST API erzeugt die du per Put/Get/Post.... nutzen kannst. Es wird aus dem Proto Contract eine OpenAPI definition erstellt, und auch eine SwaggerUI erzeugt. Das dies nicht für alle API Befehle geht, zumindest nicht in den der Server dann proaktiv was sendet ist mir klar.

HTTP Methoden wie PUT/GET etc machen noch lange keine REST API aus.
Verletzt fast alle Prinzipiel einer "echten REST API" Richardson Maturity Model nach Level 2. Dieses Level 2 ist das, was wir heute unter REST kennen.

Beispielsweise wird Resources (aus Level 1) nicht erfüllt; es ist halt mal auch ein gRPC Contract Converter.
Aber mit keinem Wort wird hier die Erwartung geweckt, dass hier eine echte REST-konforme API erzeugt wird. Das hast Du oben zwar geschrieben, dem ist aber nicht so.
Es ist eine HTTP API auf Basis eines RPC Vertrags - aber es ist kein "echtes REST".

Warum? Wenn die API die Rest Anforderungen erfüllt. (
>
)

Tut sie halt nicht. Sieht man sehr deutlich am generierten Swagger File bei 22:29.
Auf die Frage, ob ichs gesehen hab kann ich daher gut zurück fragen: hast Du denn verstanden, was er da macht - und was REST ist?
Denn er sagt es sogar, dass das ein reines Übersetzen ist. Es ist vielleicht ein Hauch von RESTful, aber eben nicht das, was man unter REST als Definition versteht (Maturity Model Level 2).

  • Beispielsweise sind die URLs eben Aktionen, keine hierarchischen Abfragen wie es bei REST vorgesehen ist
  • Beispielsweise sind die Reqest- und Response-Molle eben Aktionsmodelle (zB HellyRepoy), aber keine Entitäten wie es bei REST vorgesehen ist

> REST ist ein Datengetriebenes Vertragsmodell auf Basis von HTTP. Es hat Struktur und Entitäten
> gRPC ist ein Aktionsmodell

Es gibt leider sehr häufig das Verständnis, dass alles immer REST sei und REST immer auf alle passt.
In Wahrheit erfüllen die aller wenigsten API das Prinzip von REST; und haben die Anforderung auch gar nicht, was okay ist.
Es ist halt eine HTTP - und die erfüllt ihren Zweck.

Ich seh ~20 Dokumente im Monat, die REST APIs beschreiben - und auf Seite 2 sieht man sofort, dass das einzige, was auf eine "echte REST API" hindeutet, der Dokumentstitel ist.
Einfach weil viele Leute mittlerweile REST mit HTTP gleichstellen - was vollkommen falsch aber leider Alltag ist.
Aber nur weil etwas nicht REST ist, ist es nicht schlechter - aber es ist halt kein REST.

Mir ist schon klar das der Kunde der Rest bzw. die HTTP API und nicht den GRPC Teil nutzt keinen Rückkanal hat.

Das hat dann aber mit der Anforderung dieses Threads auch nicht mehr zutun. Ging ja explizit um einen Rückkanal.