JDownloader über API steuern

[FatManStanding]

Hallo,

ich nutze auf meinem Raspberry Pi den JDownloader als headless-Version (wird über Browser-Addon oder Android-App aufgerufen). Es gibt die Möglichkeit den über eine API zu steuern - irgendwas mit JSON. Das ist irgendwie kontra-intuitiv. Ich habe es hinbekommen mit diesem Aufruf eine Liste der Packages und dessen Dateien (Links) in den Downloads angezeigt zu bekommen:

curl -L "http://IP-des-PI:3128/downloadsV2/queryLinks?\{\}"

Der "allgemeine" Aufruf dazu lautet laut der Seite:

/linkgrabberv2/queryLinks?queryParams

Warum man jetzt hier "queryParams" durch "\{\}" ersetzen muss - keine Ahnung. Ich habe das in einem Forum so gefunden (nicht beim JDownloader). Ich erhalte eine Ausgabe in etwas so:

{
  "data": [
    {
      "name": "name-der-datei1.ext",
      "packageUUID": 1234567890,
      "uuid": 0987654321
    },
    {
      "name": "name-der-datei2.ext",
      "packageUUID": 1234567890,
      "uuid": 132435465768
    },
 ]
}

Wenn ich jetzt die Datei1 auf "enabled" setzen will sollte das so gehen:

/downloadsV2/setEnabled?enabled&linkIds&packageIds

Und jetzt bin ich komplett raus: Was setze ich anstelle von "enabled", "linkIds" und "packageIds" ein? Vermutlich irgendwas aus der Ausgabe oben. Einfach nur die UUIDs geht nicht. Auch sowas wie "linkIds=0987654321" und "packageIds=1234567890" genügt nicht. Statt "enabled" habe ich 0 oder 1 versucht.

Muss ich das in irgendeinem "JSON-Style" verpacken?

 

[Der_Dicke82]

gibt es einen Grund weshalb du nicht einfach my,jdownloader nutzen willst?

Außerdem gibt es doch eine cli steuer methode, oder nicht?

Hier hat jemand etwas in go geschrieben zur Steuerung:
Zum Projekt

 

[FatManStanding]

Ich will in der Lage sein zeitgesteuert DLs zu aktivieren. Das geht so nicht.

Ich würde auch gern dieses komische System hier verstehen und warum man nicht einfach wie bei jedem anderen Programm sowas macht wie "jdownloader --command parameter".

 

[NonOptionalName]

Schon einmal

/downloadsV2/setEnabled?true&0987654321,132435465768&1234567890

probiert? In der Beschreibung wird ja darauf hingewiesen, dass die Parameterreihenfolge wichtig sei, d.h. vielleicht müssen die Variablennamen nicht mit angegeben werden.

 

[FatManStanding]

Geht auch nicht. Es kommt

{
 "src"  : "DEVICE",
 "data" : "0987654321,132435465768",
 "type" : "BAD_PARAMETERS"
}

(und ja, ich habe die echten UUIDs eingesetzt).

In der Beschreibung wird ja darauf hingewiesen

Genau da liegt meiner Meinung nach das Problem. Es wird "hingewiesen". Es findet sich in der Beschreibung kein einziges echtes Beispiel wo konkrete Werte eingetragen wurden.

 

[NonOptionalName]

Echt übel und komisch, dass die das Json als Query-Parameter haben wollen (mit dem ganzen escaping etc.), normalerweise macht man sowas doch über curl -X POST -d "{...}" oder so.

Versuch's mal mit einem Json-Objekt, wobei ich hier nicht sicher bin, was abseits der geschweiften Klammern alles escaped werden sollte:

/downloadsV2/setEnabled?\{\"enabled\":true,\"linkIds\":\[0987654321,132435465768\],\"packageIds\":\[1234567890\]\}

EDIT:

Hier gibt es ein paar Hinweise dazu, wie man json für eine URL encoden sollte:
https://stackoverflow.com/questions/6807180/how-to-escape-a-json-string-to-have-it-in-a-url

EDIT 2:

In deren Beispiel ist es gar nicht escaped, also vielleicht doch direkt als json:

/downloadsV2/setEnabled?{"enabled": true,"linkIds": [0987654321,132435465768],"packageIds": [1234567890]}

 

[NonOptionalName]

Habe es einmal selbst getestet und mit folgendem Format bekomme ich das gewünschte Ergebnis (Deaktivieren bzw. Aktivieren eines packages im Linkgrabber:

http://localhost:3128/linkgrabberv2/setEnabled?enabled=true&linkIds=[1759575070985]&packageIds=[1759575070984]

Also soll man anscheinend die Query-Parameter mitsamt ihren Namen angeben, aber als Listenformat wird dann json (mit eckigen Klammern) erwartet. Absolut furchtbar, von der Doku (ohne konkrete Beispiele!) ganz zu schweigen.

EDIT:

Anschließendes

http://localhost:3128/linkgrabberv2/moveToDownloadlist?linkIds=[1759575070985]&packageIds=[1759575070984]

hat das Ganze dann zu den Downloads verschoben und gestartet, scheint also mit der Herangehensweise generell zu klappen.

 

[FatManStanding]

Wie sieht denn bei dir der gesamten Aufruf (inkl. curl) aus? Bei mir kommt beim ersten Aufruf:

{
 "src"  : "DEVICE",
 "data" : "/linkgrabberv2/setEnabled?enabled=true",
 "type" : "BAD_PARAMETERS"
}

Ich habe die Anführungszeichen vor http und am Ende weggelassen weil mit kommt

curl: (3) bad range in URL position 74:
http://192.168.10.23:3128/linkgrabberv2/setEnabled?enabled=true&linkIds=[123456789987654]&packageIds=[987654321987]
                                     ^

EDIT
Das Zeichen ^ steht in der Meldung genau unter der ersten Zahl nach "linkIds=["

 

[NonOptionalName]

Ich habe mit Bruno gearbeitet, aber wenn ich mir den Befehl als curl ausgeben lasse, bekomme ich

curl --request GET --url "http://localhost:3128/linkgrabberv2/setEnabled?enabled=true&linkIds=%5B1759588610287%5D&packageIds=%5B1759588610286%5D"

(neue ids, weil der Link mittlerweile ein anderer ist)

Scheint auch zu funktionieren, zumindest mit dem curl-Befehl der von Windows mitgeliefert wird. D.h. für Curl müssen die eckigen Klammern mit %5B bzw. %5D escaped werden

EDIT:

Etwas leserlicher wird es, wenn man das encoding von --data-urlencode übernehmen lässt:

curl --request POST --data-urlencode "enabled=true" --data-urlencode "linkIds=[1759588610287]" --data-urlencode "packageIds=[1759588610286]" --url "http://localhost:3128/linkgrabberv2/setEnabled"

...aber das funktioniert wohl nur, wenn man den Request als POST senden kann (was das Backend unter diesem Endpunkt aber wohl auch akzeptiert).

 

[Marco01_809]

Die API Doc ist wirklich richtig richtig schlecht, keine Beispiele oder auch nur eine Beschreibung wie Parameter zu formatieren sind. Bei den meisten Methoden steht nicht mal dabei was die Methode überhaupt tut. Die Syntax von Call ist eine ad-hoc Eigenerfindung wo man sich dazudenken muss wo die tatsächlichen Werte einzufügen sind, aber hingeschrieben haben sie das nirgendwo.

Ich glaube diese degenerierten JSON-URL-Params braucht man dann wenn der Parameter ein Objekt ist:
Siehe z.B. den /downloadsv2/queryLinks Aufruf. Das ist der einzige wofür wir ein Beispiel haben wegen der Sektion ganz oben:

CORRECT!
        /downloadsV2/queryLinks?{"packageUUIDs":[1468427395088]}

Den Parameter packageUUIDs gibt es in der Doc der Methode gar nicht. Einziger Parameter ist queryParams, das ist ein Objekt von Typ LinkQuery und darin findet sich auch das packageUUIDs Feld.

---

Ich würde daher im Allgemeinen annehmen:

/<namespace>/<methode>?(param1=)<wert1>&(param2=)<wert2>&...

1. Namen von Parametern sind optional bzw. egal, darum ist auch die Reihenfolge der Parameter wichtig
2. Werte sind immer JSON, ggf. nur ein einzelner Wert (was auch valides JSON ist!) oder ein Array oder ein komplexeres Objekt

Die in den Methoden dokumentierten Parametern müssen also wirklich echte URL Parameter sein und können nicht als JSON verpackt werden. Wenn der Parameter aber ein Objekt ist kann man dessen Felder nur als JSON übergeben.

---

Seltsam ist auch dass die Doc meint man solle Content-Type setzen:

Make sure to use the correct Content-Type. For most calls, this is application/json; charset=utf-8, see call description
The API expects JSON Input and will return JSON output. Make sure that you send valid JSON formatted text.

Content-Type setzen kann man aber nur bei POST und bezieht sich da nur auf den Body den man sendet. Die API sagt zwar dass GET und POST unterstützt werden, aber wie das JSON im Body auszusehen hat bleibt gänzlich unerwähnt
Ich hätte eher einen Body vom Typ application/x-www-form-urlencoded erwartet, das wäre selbsterklärend anhand der bekannten URL Params... Ein Versuch wert wäre folgendes:

{
    "param1": <wert1>,
    "param2": <wert2>,
    ...
}

und es würde mich nicht wundern, wenn die Werte nicht direkt JSON-Struktur sind, sondern encodeten JSON in Form eines Strings

 

[FatManStanding]

@ NonOptionalName
Dein erstes Beispiel funktioniert, das zweite habe ich noch nicht getestet. Das Programm Bruno kenne ich har nicht.

@ Marco01_809

Ja, die Doku ist gruselig, ich habe da ja noch weniger Ahnung als ihr. Ich habe mich selbst durch diesen (auch wenig gut dokumentierten) TR064-Kram bei der Fritzbox gekämpft. Da gab es wenigstens Beispiele und man könnte sich durchprobieren. In deren Forum gibt es seit min. 2009 Beiträge die genau das bemängeln: kaum zu verstehende Doku und keine Beispiele. Die Reaktion war dann eher kindlicher Trotz.

Ich danke für eure Hilfe.

EDIT

Variante 2 geht auch.

 

[NonOptionalName]

Ich habe die API in meinen Versuchen auch nicht dazu überreden können, Json als post anzunehmen. Es wird aber auf jeden Fall geparst, denn wenn man invalides json rein bastelt, bekommt man als response einen stacktrace des backends (ein weiteres nogo bei APIs btw.). Bei validem Json gibt es trotz identischen Inhalt zum funktionierenden Query einen BAD_PARAMETERS-Fehler.

Die Annahme von Listen als pseudo-Json mit eckigen Klammern scheint dieser Diskussion hier nach zufolge zumindest unkonventionell zu sein. Standardkonform wären Komma-getrennte Werte, also

values=foo,bar

oder halt eine Wiederholung des Parameternamens:

values=foo&values=bar

Von dem gruseligen session-handling, das einem bei der Arbeit mit dem lokalen Endpunkt wenigstens erspart bleibt, fangen wir am besten gar nicht erst an.