Nachdem Spymac im Thread zur Beta des Relaunchs vorgeschlagen hat, für Vorschläge und Diskussionen rund um das mgtv-API einen extra Thread zu eröffnen, komme ich dem hiermit mal nach 
Mein erster Vorschlag für ein neues bzw. erweitertes API habe ich mal in einem Dokument zusammengefasst, um es hiermit zur Diskussion zu stellen: https://thegremium.org/~doc/mgtv/api.pdf
Vielleicht wäre da auch ein Wiki-Eintrag dazu ganz praktisch, um die Ergebnisse der Diskussion hier festzuhalten?
Alle Requests als POST? Finde ich sehr merkwuerdig. Normalerweise nutzt man GET fuer Lesen und POST fuer Schreiben. Also ein GET Request liest nur einen Server State und ein Post Request modifiziert unter Umstaenden den State.
Siehe hierzu: http://evertpot.com/dropbox-post-api/
Das gefällt mir sehr gut, aber eine Frage habe ich noch bei “2.1 Magazine”
"magazines": [ <Magazine> ]
Soll dies die Untermagazine/ContentTypen/Filter beinhalten? Also bei FKTV dann (1= Folgen, 2 = Postecke, 3 = Interviews, 4 = Extras, 5 = Sendeschluss).
Ich vermute mal schon weil alles andere keinen sinn ergäbe, aber 100%ig ersichtlich ist es für mich nicht.
[QUOTE=STaRDoGG;425913]Alle Requests als POST? Normalerweise nutzt man GET fuer Lesen und POST fuer Schreiben.[/QUOTE]
Ja, aber mit einem GET kannst du nur schwerlich komplexere Daten an den Server übermitteln (siehe z.B. http://stackoverflow.com/a/983458), was aber gerade bei Filter-Einstellungen recht nützlich wäre. Man könnte natürlich die Filterdinge auch entsprechend serialisiert in einem Request-Parameter übergeben, aber auf dem Weg zwischen User und Server könnten da irgendwann mal Längenprobleme bei der URL auftauchen.
… und wenn man wegen komlexeren Sachen wie Filter eh schon POST machen möchte, dann kann man den Rest auch gleich noch im Body übertragen, und das auch gleich grundsätzlich festschreiben.
Ich will’s halt nicht zu kompliziert machen - auf diese Weise würde man überall mit JSON hantieren, sowohl bei der Ausgabe als auch der Eingabe, und das sowohl auf dem Server als auch dem Client; lässt sich auch sehr bequem mit AngularJS zusammenschrauben auf diese Weise.
[QUOTE=Arwarld;425917]Das gefällt mir sehr gut, aber eine Frage habe ich noch bei “2.1 Magazine”
"magazines": [ <Magazine> ]
Soll dies die Untermagazine/ContentTypen/Filter beinhalten? Also bei FKTV dann (1= Folgen, 2 = Postecke, 3 = Interviews, 4 = Extras, 5 = Sendeschluss).[/QUOTE]
Genau, das dient dazu, dass man eine Hierarchie aufbauen kann (wie in deinem Beispiel bei FKTV) - eben ein Array mit wiederum der Magazine-Struktur (das wiederum ein Array mit Magazinen enthält, was aber im Moment keiner nutzt g).
Es enthält aber wirklich nur (Unter-)Magazine, keine anderen Content-Typen.
Was mir da noch auffällt: vielleicht sollte man in 3.2 getClips statt einer magazineID ein Array magazineIDs übergeben, um gleich mehrere Magazine (z.B. FKTV und dessen Untermagazine FKTV-Folgen, FKTV-Postecke …) auf einmal abrufen zu können?
Ich finde es halt auch ziemlich bloated und unnoetig komplex. getMagazines und getClips koennte man einfach “flach” machen und die Parameter in einem GET Request nutzen - Laengenprobleme sehe ich hier keine. Ich sehe irgendwie nicht die Notwendigkeit fuer komplexe verschachtelte JSON Objekte.
EDIT: Aber ok … ich will dir nicht in die Suppe spucken. Letztendlich werde ich eh keine Client Applikation schreiben und daher betrifft es mich sowieso nicht. Aber da du ja anscheinend die momentane API komplett verworfen hast wird es dein Vorschlag eh schwer haben :ugly.
Im Moment dürfte es da auch keine Längenprobleme geben; man muss es nur im Hinterkopf behalten.
Bezogen jetzt auf die Richtung Client -> Server, oder Server -> Client (oder überhaupt g)?
Tust du doch nicht - dafür ist dieser Thread doch da, dass man diskutieren kann, was man wie machen könnte und warum 
Naja, die momentane API ist halt nur eine etwas aufgebohrte Version des bisherigen Wirrwarrs - mein Vorschlag dient dazu, das auf dem Reißbrett sauber neu und zukunftssicher zu entwerfen, und das möglichst so, dass alle Beteiligten möglichst wenig Aufwand haben, das zu implementieren - auch ein Gedanke, der hinter dem JSON-POST-Zeug steckt, weil so z.B. auf Server-Seite einfach der Body genommen und per json_decode zu nem PHP-Objekt gewandelt werden kann, so dass man das dort leicht weiterverarbeiten kann. Umgekehrt kann man auf Client-Seite ebenso leicht JSON erzeugen, sei es nun in einer Webapplikation per JSON.stringify oder in Java mit gson oder in C# mit JSON.net oder … - das klatscht man dann einfach in den POST-Body, fertig.
Ob unsere API-Diskussion hier am Ende dazu führt, dass das auch bereitgestellt wird, ist natürlich grundsätzlich ein Problem - aber ich hoffe, dass eine möglichst nachvollziehbare und leicht zu implementierende Beschreibung dazu beiträgt, dass das am Ende was wird - zumal man das ja erst mal auch alles parallel laufen lassen kann, die bisherige v1 und die neue v2. Im Moment läuft die v0 ja auch noch (wobei’s da interessant ist, bis wann die dann noch verfügbar sein wird - nicht, dass ich jetzt schon zusehen muss, die v1 in die App zu integrieren [um dann ggf. nochmal wegen URL-Change ein Update in den Store schieben zu müssen]).
Super Vorschlag!
Gerade da MG-TV in Zukunft weiter wachsen wird (nach aktuellem Stand) - sollte dann auch die neue Webseite entsprechend zukunftsicher gemacht werden - denn nichts ist ärgerlicher als am Ende alles doppelt programmieren zu müssen ^^
Von dem her, guter Mann, guter Vorschlag!
Ich habe die API-Ideensammlung mal überarbeitet und erweitert; die wesentlichen Änderungen: hinzugekommen sind die Requests “setAlreadyWatched” und “setLastKnownPosition”, HTTP GET auch als Transportmittel definiert.
Sieht für ein Apivorschlag erstmal nicht schlecht aus und wirkt durchdacht. Zu POST oder GET werde ich erstmal nichts schreiben, weil die Annahme der Requests von Server-Software zu Server-Software unterschiedlich ist wie groß sie sind und ich habe da keinen direkten Einblick.
Ich würde bei den Fehlern noch einen Fehlercode hinzufügen um nicht direkt einen String auswerten zu müssen um auf Fehler evtl zu reagieren bzw zu loggen. Allgemein müssen Fehlerfälle bei einer Api dokumentiert werden.
Aufgezeichnete Live-Übertragungen sind glaub ich auch noch nicht vorgesehen oder? Diese haben für gewöhnlich ja keinen Teaser.
Was auch cool wäre, wären related Videos in den Clips aufzunehmen (Interviews in der Folge etc).
Basic Auth finde ich nicht besonders sinnvoll, weil die Zugangsdaten dann immer in der Hand vom Apinutzer liegen. Da wäre ein Authentifizierungstoken wie OAuth2.0 oder ähnliches sinnvoll. Das kann man einfach abschalten, wenn man der Software nicht vertraut und erweckt mehr Vertrauen als User.
Gute Idee; so lange die Codes sauber definiert sind 
Ja, aber das müsste von demjenigen gemacht werden, der die Fehlerrückmeldung liefert - sprich: das muss seitens Alsterfilm passieren, eigentlich.
Noch schlimmer, glaube ich - auch Live-Live-Übertragungen scheinen bisher nicht vorgesehen zu sein.
Dafür habe ich die „links“ eingefügt in das Clips-Objekt, um solche Verlinkungen zu ermöglichen.
Nun, das ist letzten Endes nur eine Fortführung des bisherigen API-Handlings (und einfach zu implementieren); ich persönlich könnte damit weiterhin leben, aber von mir aus darf’s auch gerne OAuth 2.0 sein Bisher hat sich zum API-Vorschlag ja nur die Client-Seite geäußert, die Sicht des mgtv-Admins fehlt noch 
Ja, bedeutet aber auch mehr Implementierungsaufwand auf Server-Seite (jetzt nicht nur für das grundlegende OAuth-Handling, sondern man bräuchte dann ja auch noch eine Token-Verwaltungs-Oberfläche). Fände ich grundsätzlich aber auch nicht schlecht.
Ich weiß jetzt nur nicht, wie sowas z.B. in Kodi möglich ist - OAuth auf Android sollte jetzt nicht das große Ding sein, da gibts auf das erste googlen hin schon fertige Libraries, die man verwenden kann, aber ob das auch bei anderen Systemen so einfach ist (im Gegensatz zu HTTP BASIC Auth, das ist letzten Endes ein simpler Header der mitgeschickt werden muss) -> keine Ahnung. Und die sollen ja auch nicht ausgeschlossen werden find
Danke für euer Feedback. Bei deinem Vorschlag sind einige interessante Sachen für eine v2 dabei.
Ein paar Sachen würde ich entschlacken. Prinzipiell sind das aber Sachen die man durchaus in Angriff nehmen kann. Logischerweise aber erst nach dem Launch.
Live Übertragungen sind durchaus auch für die API vorgesehen und aktuell sogar schon (sozusagen v0) im XMBC Plugin (Wenn es nicht rausgenommen wurde) vorhanden. In der v1 aber richtigerweise noch nicht übernommen.
Spymac: Kann man eigentlich auch irgendwie effizienter mit dir in Dialog treten als nur alle paar Wochen mal ne Nachricht im Forum auszutauschen? 
Also, kA, per eMail, IRC, PM, … ?
Hallo
Hier pspzockerscene vom offiziellen JDownloader Support. [verifizierbar über die angemeldete E-Mail]
Erstmal wer nicht weiß was JDownloader ist:
http://jdownloader.org/
Kurzform: Ein bekannter Downloadmanager geschrieben in Java, der u.a. Massengeschmack/Fernsehkritik.tv schon sehr lange unterstützt.
Nur um zu zeigen, dass das Thema aktuell ist - hier ein aktueller Thread aus unserem Forum dazu:
https://board.jdownloader.org/showthread.php?t=66915
Nachdem ihr eure Seite mal wieder umgestellt habt und ich im Forum die Windows App und das Kodi Plugin gefunden habe war mir klar, dass es eine API geben muss und ich hätte sowieso früher danach schauen sollen 
Grundsätzlich sollte die bestehende API für unsere Vorhaben ausreichen - dennoch einige Fragen/Vorschläge:
Sehe ich das richtig und es wird gerade an der V2 gearbeitet?
Dann macht es wohl wenig sinn, die V1 jetzt einzubauen ?!
Für JDownloader wäre noch ein Aufruf praktisch, der Informationen über den Account zurückgibt und zwar:
-Account Typ (Free/Premium / Was ist aboniert)
-Ablaufdatum
Es würde sich anbieten, sowas als eine Art Login-Funktion zu machen - beim Loginversuch mit falschen Daten bekommt man eine Fehlermeldung, ansonsten die Accountinformationen.
Es wäre toll, wenn die API einerseits auch ohne zugangsdaten funktionieren würde eben für Inhalte, die auch so komplett schaubar/ladbar sinds (auch wenn das nicht viele sind).
Außerdem fände ich es praktisch, wenn die API auch ohne Account Infos liefern würde z.B. hier könnte man alles liefern außer eben die Downloadlinks:
https://massengeschmack.tv/api/v1/?action=getClip&identifier=sakura-4
Ich weiß nicht wie es mit den FREE fernsehkritik.tv Folgen aussieht - JDownloader kann die schon lange laden auch wenn ich verstehen kann, dass das offiziell nicht gewollt ist.
Ein API aufruf dafür wäre auch toll, aber ich kann voll und ganz verstehen falls es das nicht geben wird
Werden „alte“ API Versionen auch noch einige Zeit aktiv bleiben sofern neue fertiggestellt sind oder schaltet ihr die alten dann sofort ab?
Ein „API-Newsletter/Changelog“ für Entwickler wäre hier eventuell interessant, sodass man bei Änderungen / Updates per E-Mail benachrichtigt wird.
Was passiert mit den Livestreams bzw Aufzeichnungen?
Ich nehme an, die gibt es nicht mehr lange, da sie auch jetzt schon nicht mehr funktionieren (Videos laden nicht, finale hls URLs führen ins Nirvana):
https://massengeschmack.tv/live/spendennacht1
https://massengeschmack.tv/live/ptv54
https://massengeschmack.tv/live/np48
https://massengeschmack.tv/live/ps52
Wäre es möglich, einen Test-Account zu bekommen sobald der Einbaue der API abgeschlossen ist?
Ich bin wirklich nicht geizig, aber habe aktuell kein Abo und bin daher immer auf freiwillige Benutzer angewiesen, die mir ihre Zugangsdaten zum Beheben von Massengeschmack-JDownloader Problemen schicken …
Ich muss sagen ich bin POSITIV überrascht, dass ihr überhaupt eine API habt.
Grüße, pspzockerscene - Offizieller JDownloader Supporter & Plugin Entwickler
@pspzockerscene
Habe selbst erst ehr zufällig gesehen, das der jDownloader MG unterstützt. Da du das Plugin dazu geschrieben hast: Danke 
.
Wenn ich richtig informiert bin ist schreibt nur Spymac an der Seite und eben auch an der API.
Hoffe er hat die Zeit sich bei dir zu melden um das Plugin für den JD aktuell zu halten.
Ich nehme an dir geht es im wesentlichen um direkte Angabe des Clips. Dann ist es ziemlich simpel den Download zu erhalten. Auch für kostenlose Clips. Diese URL leitet einfach auf die entsprechende Version weiter. Falls die Version einen Zugang benötigt, wird danach gefragt.
Zum Beispiel:
https://massengeschmack.tv/dlr/sakura-5/mobile.mp4
Die Liveaufzeichnungen werden sehr regelmäßig gelöscht und sind aus diversen Gründen nicht geeignet zum Archivieren. Natürlich gibt es da immer ein paar Ausnahmen.
Über eine offene API kann man bei der v2 mal drüber nachdenken.
Alte API Versionen bleiben erstmal einige Zeit noch online.
Für Fernsehkritik-TV oder generell werbefinanzierte kostenlose Versionen, bei denen kein kostenloser Download angeboten wird, wird es natürlich keine Download-API geben.
@partizipator
Naja wenn massengeschmack mag können sie auch gerne offiziell damit werben, dass es JD Unterstützung gibt.
Im Endeffekt würden auch Werbung/Verlinkungen für das KODI Plugin und die Windows(Phone) App nicht schaden!
@Spymac
Danke sehr praktisch!
Was ich übrigens mit Punkt #3 bezüglich der API meinte ist, dass es praktisch wäre, wenn die API auch ohne Login alle Daten zu Inhalten zurückgeben würde außer eben die Downloadlinks z.B. so:
{
"identifier": "sakura-4",
"pid": 9,
"title": "Folge 4",
"pdesc": "Sakura",
"img": "\/\/cache.massengeschmack.tv\/img\/mag\/sakura-4.jpg",
"desc": "In unserem Anime- und Manga-Magazin wird diesmal dem Ph\u00e4nomen \"Boys Love\" auf den Grund gegangen. Warum haben insbesondere weibliche Fans ihre Freude daran? Au\u00dferdem geht es um \"Elfen Lied\" und \"Neon Genesis Evangelion\". Und im Talk geht es um die Faszination von Cosplays.",
"duration": "01:11:46",
"date": 1437478870,
"subscribed": false,
"teaser": "http:\/\/dl5.massengeschmack.tv\/deliver\/teaser\/limited\/teaser_sakura4.mp4",
"files": [
{
"size": 2666360644,
"t": "film",
"size_readable": "2,48 GiB",
"dimensions": "1920x1080",
"desc": "HD 1080p",
"url": null
},
{
"size": 1066456085,
"t": "film",
"size_readable": "1017 MiB",
"dimensions": "1280x720",
"desc": "HD 720p",
"url": null
},
{
"size": 618324565,
"t": "film",
"size_readable": "590 MiB",
"dimensions": "720x406",
"desc": "SD 406p",
"url": "null
}
]
}
Was mir auch noch einfällt:
Es wäre praktisch, wenn es ein Feld „episodenumber“ oder so im json geben wird.
Will man mit Episodennamen irgendwas anfangen muss man diese aktuell immer umständlich aus den Titeln holen und kann sich dabei nicht sicher sein, ob es überhaupt eine Episode ist z.B. „Spendennacht 1“ ist doch eher „Spendennacht 1“ als „Spendennacht Episode 1“, sprich, eigentlich keine richtige Episode im sinne von Episode einer Staffel oder eines richtigen Formates (ich hoffe du verstehst was ich meine).
Außerdem hast du mir jetzt zwar gezeigt wie man ganz einfach die „BESTe“ Qualität bekommt, allerdings könnte man die zusätzlich im json angeben.
Aktuell hole ich mir ein Array des htmls (bzw per API dann das json), durchlaufe das und lade immer die Version mit der höchsten Dateigröße.
Solche Sachen könnte man sich dann sparen.
… aber ich will hier keine zu hohen Ansprüche stellen - schön, dass des überhaupt eine API gibt
Gibt es ein ungefähres Datum der V2?
Ansonsten kann ich die V1 ja eigentlich auch verwenden - sollte in jedem Fall besser sein als die Webseite zu nutzen.
Grüße, pspzockerscene - Offizieller JDownloader Supporter & Plugin Entwickler
EDIT
Ich habe die API mal eingebaut.
Ich habe alles so umgesetzt, dass sowohl Webseite als auch API berwerndet werden, da ich per API noch nicht an alle Infos bekomme, die ich gerne hätte (z.B. Account Ablaufdatum).
Zudem finde ich das Rate Limit relativ heftig - falls Leute (z.B. mit JD) viele Sachen laden wollen kommt man schnell an die grenze.
… aber gut - Errorhandling dafür habe ich eingebaut.
Als User-Agent für API Aufrufe habe ich „JDownloader“ genommen falls ihr z.B. Statistiken für die Nutzung machen wollt.
Entschuldigt den Doppelpost - scheinbar kann man bei euch im Forum die Posts nur für eine bestimmte Zeit nach dem Posten editieren^^
Also ich habe einen kleinen API Bug gefunden:
→
https://massengeschmack.tv/api/v1/?action=getClip&identifier=asynchron-16
Sowohl per API als auch per Webseite stimmt die Dateigröße der BEST (=HD) Version NICHT.
Angegebene Dateigröße: 668 MiB
Tatsächliche Dateigröße: 1,3 GB
Schlimm ist dies zwar nicht, aber es wäre nett, wenn die Herren der Technik überprüfen würden, ob dieses Problem auch bei anderen Videos besteht
Grüße, pspzockerscene - Offizieller JDownloader Supporter & Plugin Entwickler
EDIT
Nebenbei angemerkt noich 2 Probleme der fernsehkritik.tv Webseite:
Außerdem sind 2 Feedbacks verlinkt, die es (noch) nicht [im neuen System] gibt:
http://massengeschmack.tv/play/0/direkt-30
http://massengeschmack.tv/play/0/direkt-31
(Auch hier sind die massengeschmack URLs falsch!)
Und nochwas:
Wie ich sehe bekommt man per Feed auch die Dateigrößen-Informationen, wenn man kein Abo/Download Zugriff auf die Inhalte hat:
https://massengeschmack.tv/feed/main/hd.xml
Aus diesem Grund finde ich, sollte man diese Infos auch per API immer bekommen;)
Grüße, pspzockerscene - Offizieller JDownloader Supporter & Plugin Entwickler
Gut das du die Fehler meldest die du beim abrufen, arbeiten findest.
Das KODI Plugin und die Windows Phone App die den Abruf über die API unterstützen kenne ich nicht, welche Nutzer profitiren davon?
Was eine ganz andere Baustelle ist aber super interessant weil die Großen wie Gronkh und Retro.tv dort zu finden sind ist
das http://www.dreambox-blog.com/index.php/7919/mediaportal-bringt-60-mediatheken-auf-die-dreambox
Mediaportal was meines Wissens nach nicht nur auf der Dreambox läuft sondern auch auf anderen Images instlliert werden kann.
Vielen Dank das du MG in den JD einpflegst…
Ich bin immer sehr froh, wenn sich engagierte Menschen finden die zur Verbreitung beitragen und den Zugang über unterschiedliche Programme und eben auch Apps ermöglichen.
OT:
@partizipator
Erstmal danke bzlg. dem (jd) Feedback.
Zu der Windows Phone App kann ich nichts sagen, da ich ein Android Handy habe, aber KODI ist eine viel größere „Mediathek“ als deine Dreambox
http://kodi.tv/download/
Über Plugins werden hunderte von Webseiten unterstützt - drunter auch ALLE Mediatheken.
Zudem läuft es auf allen gängigen Plattformen / TV Sticks.
So nun gnug Offtopic - ich warte auf Antworten der Technik
Grüße, pspzockerscene - Offizieller JDownloader Supporter & Plugin Entwickler