Hallo Guido & Co.

Ich wollte mal fragen, was ihr davon haltet eine kleine API für SKL bereitzustellen. Ich habe zu dem Thema bisher nur diesen alten Post gefunden: http://www.sandkastenliga.de/jforum/posts/list/92.page

Auch wenn die Implementierung für euch sicher etwas Arbeit bedeutet, könntet ihr IMHO dadurch nur profitieren, da ihr so der Community die Möglichkeit gebt eure Arbeit zu unterstützen. Und gerade hier bei der doch sehr hohen Dichte an (Ex-)HPIlern dürfte da einiges von der Community kommen.

Ich persönlich hätte z.B. richtig Lust ne iPhone-App für SKL zu schreiben, oder auch ein OSX Dashboard Widget. Die API müsste ja erstmal nicht den vollen Funktionsumfang bieten - ein Zugriff auf Live-Ergebnisse und Tipps wäre z.B. schon mal ein super Anfang.

Ich schreib das hier auch nicht um "Stress zu machen" oder mich zu beschweren - ganz im Gegenteil: Ich finds super, was ihr hier aufgebaut habt und würde mich gerne aktiv etwas daran beteiligen

Gruß,
Daniel

Schließe ich mich an. Momentan (oder wie immer) zwar ne Zeitfrage, aber mittelfristig kann ich mir auch gut vorstellen, das zu nutzen.
Gebastelt hab ich ja auch schon mal. Und ich werde auch weiterhin schön per Twitter über Liveergebnisse informiert.
http://sandkastenliga.de/jforum/posts/list/304.page

Hi Silvan,

coole Sache, danke. Also dein Ruby-Skript würd mich schon interessieren. Allerdings würde ich für etwas komplexere Sachen (iPhone-App z.B.) nur seeehr ungerne Webscraping machen - zumal das in Objective-C definitiv keinen Spaß macht RSS/Atom oder halt ne API wären da schon sehr schick.

Zeitlich siehts bei mir auch nicht so toll aus, aber so als Wochenend-Projekt könnt ich mir sowas schon vorstellen. Evtl. auch mit mehreren zusammen oder so.

Gruß,
Daniel

Hi Daniel,

ich hatte das vor etwas mehr als einem Jahr schonmal als Ticket formuliert. Damals hatten wir es niedriger priorisiert, weil kein unmittelbarer Nutzen zu erkennen war.

Wenn du aber tatsächlich anbietest eine iPhone-App zu stricken, können wir das natürlich gerne auch kooperativ angehen. Ich denke, eine Bereitstellung von RSS-Feeds für verschiedene Spiel-/Mannschafts-/Trainer-Daten sollte recht schnell machbar sein.

Die Weihnachtspause wäre auch eine hervorragende Zeit um das gemeinsam anzugehen. Wenn du also eine gewisse Grundvorstellung für die App hast (nur Viewer, oder auch Änderungen, Chat, etc.) dann könntest du das ja mal in einer Email an mich und Guido schicken. Dann sehen wir zu, dass du die nötigen Daten möglichst schnell und unkompliziert auch automatisiert abrufen kannst...

Gruß,
Torben

P.S.: Gerne biete ich mich auch als iPhone-Testuser an...

Torben Schreiter wrote:P.S.: Gerne biete ich mich auch als iPhone-Testuser an...

wenn ihr noch nen testuser braucht, ich bin dabei!

Ich auch
Im Ernst, jede Hilfe ist willkommen. Zwecks Priorisierung wäre es natürlich hilfreich, etwas mehr Informationen zu bekommen.

1) Welche Aret von Schnittstelle hättens denn gern? SOAP Service, REST Service, JSON, RSS, ...

2) Welche Funktionen hättens denn gerne in der ersten Version? Nut lesen oder auch scheibend? Also ein Tipp-Widget, das man irgendwo außerhalb der Sandkastenliga nutzen kann (z.B. Netvibes oder iGoogle) wäre ja auch was Nettes.

3) Warum nicht gleich Commit-Rechte auf unserem SVN? Ich hätte kein Problem damit, wenn Du das direkt bei uns im System machst, solange Du nicht mit Vorschlägen wie: "Jetzt müssen wir aber erstmal die Architektur grade ziehen" oder "Ich kann da so ein cooles neues Framework, lass uns mal alles auf das umstellen" kommst.

Gruß
Guido

Neue Notiz 256

@Daniel, hab dir den Code geschickt, wenn's nicht ankam, melde dich nochmal, ich war nicht ganz sicher mit der E-Mail-Adresse.

Wie gesagt, ich werde selbst erstmal nicht dazukommen, gebe aber einfach dennoch mal meinen Senf mit ab

@guido
zu 1: Die Schnittstelle ist vermutllich Geschmackssache. Ich persönlich finde die Goolge Rest/Atom APIs [1] schön sauber. Da könnte man auch erstmal nen Feed mit Ergebnissen anbieten und nach und nach weitere Funktionen hinzufügen. Aber ich denke das ist flexibel.

zu 2: Meine persönlichen Prios (absteigend):

Lesen der Sandkastenliga-Live-Events

Lesen meiner Live Tippergebnisse

Tippen

Auf's Spiel live Einfluss nehmen: Motivation, Härte, Auswechslungen

Chat, Forum lesen, Manschaftseinstellungen vornehmen und alles andere

zu 3:
Der Vorteil einer API wäre, dass du da fast jeden drauflassen kannst, ohne seine Commits überprüfen zu müssen oder ihm überhaupt vertrauen zu müssen. Für Sachen, die die Systemfunktionalität betreffen oder z.B. um gemeinsam die API zu entwickeln wär das natürlich ne feine Sache.

[1] http://code.google.com/apis/gdata/overview.html

Aber zur Google API gibt es keine server-seitige Library, oder?

Huch, hat sich ja einiges getan hier..

Also, ich arbeite das mal der Reihe nach ab:

Torben wrote:Wenn du aber tatsächlich anbietest eine iPhone-App zu stricken, können wir das natürlich gerne auch kooperativ angehen. ... Die Weihnachtspause wäre auch eine hervorragende Zeit um das gemeinsam anzugehen. Wenn du also eine gewisse Grundvorstellung für die App hast (nur Viewer, oder auch Änderungen, Chat, etc.) dann könntest du das ja mal in einer Email an mich und Guido schicken.

Wie die meisten von uns, hab ich im moment auch nicht gerade Zeit in rauen Mengen im Überfluss. Insofern wäre das Ganze wirklich nur ein Hobby-Projekt, bei dem ich jetzt auch keine (Zeit-) "Garantien" geben möchte Aber ich denke, wenn sich da vielleicht noch der ein oder andere findet mit dem man sowas zusammen angehen kann, könnten wir da schon was cooles auf die Reihe bekommen. Genaue Vorstellungen hab ich bisher noch nicht, aber ich könnte ja mal in den Weihnachtsferien ein paar Wireframes malen (@Silvan: hat rapidrabb.it schon iPhone Support? ).

Guido wrote:Welche Aret von Schnittstelle hättens denn gern? SOAP Service, REST Service, JSON, RSS, ...

REST (echtes, nicht dieses Pseudo-REST vieler APIs) mit JSON Repräsentation wäre sicher das einfachste, gerade wenn man es in JS-basierten Widgets wie iGoogle/Netvibes nutzen will (auch aufm iPhone ist JSON etwas leichter zu parsen als XML). Aber Atom wär auch ok. Alles nur kein SOAP, aber das hast du ja wahrscheinlich nicht ganz erst gemeint

Guido wrote:Welche Funktionen hättens denn gerne in der ersten Version? Nut lesen oder auch scheibend? Also ein Tipp-Widget, das man irgendwo außerhalb der Sandkastenliga nutzen kann (z.B. Netvibes oder iGoogle) wäre ja auch was Nettes.

Klar, deswegen hab ich das ganze ja überhaupt vorgeschlagen. Ich denke, wenn man erstmal ne API hat, dann fallen einem 1000 coole Sachen ein die man bauen kann. Was die Features angeht schließe ich mit Silvan zu 100% an, auch was die Prios angeht. Erstmal vor allem lesender Zugriff auf die Live-Ergebnisse und evtl. Tipps, und erst später schreibend.

Guido wrote:Warum nicht gleich Commit-Rechte auf unserem SVN?

Das wäre sicher nützlich, um die API zusammen zu entwickeln. Aber würd schon nicht schaden, wenn einer von euch da auch etwas Hand anlegen könnte, sonst wirds dann doch etwas viel..

Gruß,
Daniel

Also ich werde keine Diskussionen darüber anfangen, ob die API nach reiner REST-Lehre gebaut und philosophisch und esotherisch ok ist oder nicht. REST heißt für mich HTTP Aufruf mit Query Parametern (dabei ist es m.E. egal, ob da ein ? oder ein / zwischen den Parametern steht) rein (entw. GET für lesend oder POST für schreibend), Antwort zurück ohne elektronischer Schnittstellenbeschreibung (also schön Textdokumente lesen). Was es gegenüber SOAP zwar einfacher in der Verwendung zur Erzielung erster Erfolgserlebnisse macht, aber ich verwette meinen Hintern darauf, dass bald die ersten RSDL Derivate auftauchen werden, womit wir dann wieder fast bei SOAP wären. Jaja, ist ein Widerspruch in sich, sagen die REST-Fans. Hört sich für mich so an wie das Mantra, das Apple Jahrzehntelange vor sich hinfaselte: "Eine Maus braucht nur einen Button", "Motorola-Zyklen sind doppelt so effizient wie Intel-Zyklen.".

SOAP wären für mich ein paar Annotationen im Code, REST eine völlig neue Implementierung. Aber da ich SOAP auch für zu umständlich halte, können wir das gerne mit REST (wie oben beschrieben) machen.

Kann mir jemand mal ein Beispiel zeigen, wie man eine REST Schnittstelle am besten spezifiziert (denn die wird man ja auch bei REST brauchen)? Also ein Word- oder HTML-Template oder so?

Gruß
Guido

Hi Guido,

also zunächst mal: Es war nicht meine Absicht hier eine Grundsatzdiskussion über API-Architekturen loszutreten.. Ich bin auch kein Architektur-Esotheriker, Hauptsache ist dass es funktioniert und ohne große Mühe zu implementieren ist (sowohl auf Server- als auch auf Client-Seite).

Trotzdem möchte ich nochmal kurz was klarstellen: Leider ist ReST irgendwie zu einem Buzzword geworden, bei dem viele nicht zu wissen scheinen, was es eigentlich bedeutet. Viele API-Provider denken wohl "Unsere API basiert auf HTTP, also ist es wohl das tolle, neumodische ReST". Neben einigen anderen ReST-Prinzipien wie Zusatandslosigkeit (um die es mir hier auch garnicht ging), sollte eine API, die sich ReST nennt halt zumindest mal Ressourcen-orientiert und nicht Prozedur-orientiert sein. Vgl:

GET /foos/1 bzw. POST /foos/1

und

GET /getFoo?id=1 bzw. GET /updateFoo?id=1

Gutes Beispiel für solche Methoden-basierten "ReST"-APIs ist die RememberTheMilk API (http://www.rememberthemilk.com/services/api/request.rest.rtm) oder auch Flickr API - die nun wirklich alles sind, nur kein ReST (und das ist das was ich mit "nicht Pseudo-ReST" meinte). Und wie die URLs aussehen ist völlig nebensächlich.. Was ich eigentlich hiermit sagen will: Mich stört nicht, dass diese APIs sowas wie "RPC-over-HTTP" sind, sondern eher, dass sie blind als "ReST" bezeichnet werden. Ich denke, eine klare Begrifflichkeit sollte schon sein, sonst redet man aneinander vorbei.

Ok, zurück zur eigentlichen Sache: Wie oben schon gesagt ist es mir ziemlich egal, wie die API aussieht. Und ich kann vollkommen verstehen, dass man auf ein bestehendes System nur schwer eine wirkliche ReST-API draufsetzen kann, denn das ist eher ein grundlegender Architekturstil. Insofern höre ich jetzt auch auf, hier so pingelig zu sein und wir vertragen uns wieder

Gruß,
Daniel

Hi Daniel,

sollte auch nicht so rüberkommen, dass ich denke, dass Du Architektur-Esotheriker bist
Ich finde es ja super, wenn jemand Lust verspürt, vielleicht mal was zur Sandkastenliga beizustragen. Bzgl. Begrifflichkeit gebe ich Dir völlig Recht. Sollte schon klar sein.
Mein Problem ist, dass ich ohne weiteres eine "RPC over HTTP" Schnittstelle bereitstellen könnte. Bei REST müsste ich mich erst noch in Jersey einarbeiten. Das würde ich soger gerne machen, weil es mich interessiert. Andererseits sind mir die Vorteile nicht klar. Um die rauszufinden, müsste man vermutlich wissen, was wohl am einfachsten für den Client ist.
Wenn wir mal iPhone nehmen: Eine iPhone App ist m.W. nach in Objective-C gebaut, wenn sie nativ sein soll. Was passt da als API für Remote Calls am besten? Da kenne ich mich so gar nicht aus. Wichtiger wäre vermutlich noch, welches Antwortformat denn am Besten ist. Ich hab nie verstenden, wozu man eine XML-Kommunikation braucht, lass mich aber gerne eines bessern belehren. Für reines Frontend mit JavaScript wäre vermutlich JSON einfacher.
Fragen über Fragen.

Gruß
Guido

Hi Daniel.

ich experimentiere gerade mit REST. Ein paar Fragen hierzu (keine Angst, Du bist nicht gezwungen, etwas degegen zu programmieren):

1.) JSON oder XML (ich präferiere Ersteres)?

2.) Was ist Deiner Ansicht nach der bessere Content Type beim Erstellen oder Ändern von Ressourcen: application/x-www-form-urlencoded oder XML/JSON?

3.) Zur Authentifizierung verwende ich derzeit einen Cookie, der das Authentifizierungs-Token enthält. Laut REST-Philosophie ist das OK, da ich auf dem Server keinen Client-Status speichere, sondern im Token alles Wichtige eincodiert ist. Ist das eine vernünftige Lösung? Die Alternative wäre, dass bei jedem Request das Token auf andere Weise mitgegeben werden muss.

Danke für Deine Ansichten.

Gruß
Guido

Hi Guido,

Guido Laures wrote:
ich experimentiere gerade mit REST. Ein paar Fragen hierzu (keine Angst, Du bist nicht gezwungen, etwas degegen zu programmieren):

das ist ja echt Gedankenübertragung, ich habe mich vorgestern tatsächlich mal rangesetzt ne native iPhone-App anzufangen Ich wollte demnächst mal hier im Forum meine Gedanken zu den Features/Featureprioritäten/Milestones zur Diskussion stellen und auch ein paar Wireframes meiner UI-Pläne vorstellen.

Guido Laures wrote:
1.) JSON oder XML (ich präferiere Ersteres)?

Ja, auf jeden Fall. Ich denke mit JSON kann eigentlich jeder umgehen und für so Sachen wie Widgets (Netvibes/iGoogle/Dashboard) ist es wahrscheinlich auch wesentlich einfacher als XML. Aufm iPhone könnte die Unterstützung etwas besser sein (die Library die ich zur Zeit verwende kann z.B. keine Dates - aber da kann man sich ja behelfen indem man den Timestamp als epochen-int darstellt), funktioniert aber sonst super.

Guido Laures wrote:
2.) Was ist Deiner Ansicht nach der bessere Content Type beim Erstellen oder Ändern von Ressourcen: application/x-www-form-urlencoded oder XML/JSON?

Also zum Anlegen neuer Ressourcen ist wahrscheinlich JSON sinnvoller. Allerdings dürften sich bei den meisten schreibenden Zugriffe hier in der SKL die Properties, die geändert werden (dürfen) ja wirklich auf eine kleine Teilmenge der Gesamtressource beschränken, oder? Kommt natürlich drauf an, wie man die Ressourcen entwirft, aber wenn man mal davon ausgeht, dass wir z.B. eine Ressource für die SKL-Mannschaft haben: Der einzige Wert, den ich da frei über die API ändern kann/soll/darf wäre ja sowas wie Härte (und vielleicht später mal die Aufstellung). Liga dürfte komplett read-only sein. Bei den Tips kann man auch nur die Tips selbst ändern. Insofern wäre es wahrscheinlich wirklich das einfachste hier application/x-www-form-urlencoded zu nehmen. Klar man könnte natürlich auch nur einzelne Properties per JSON/XML übertragen, aber das fühlt sich irgendwie nicht "richtig" an.

Guido Laures wrote:
3.) Zur Authentifizierung verwende ich derzeit einen Cookie, der das Authentifizierungs-Token enthält. Laut REST-Philosophie ist das OK, da ich auf dem Server keinen Client-Status speichere, sondern im Token alles Wichtige eincodiert ist. Ist das eine vernünftige Lösung? Die Alternative wäre, dass bei jedem Request das Token auf andere Weise mitgegeben werden muss.

Ja, die liebe Authentifizierung.. Da standen wir auch bei anderen Projekten vor der Wahl, aber richtig perfekt finde ich keine Lösung. Ich kann mit der Session-Cookie-Lösung aber sehr gut leben - im iPhone hab ich ja z.B. auch einen vollständigen HTTP-Client, der auch automatisch mit Cookies umgehen kann. Und selbst wenn ein Client mal keine Cookies unterstützen sollte, kann man die JSESSIONID ja immernoch als GET-Parameter dranhängen. Allerdings ist noch die Frage, wie man sich dann initial authentifiziert (also, wie man an den Session-Cookie kommt). Ich würde vorschlagen, da einfach die Credentials (application/x-www-form-urlencoded) an /api/login oder so zu POSTen.

Sonst wird bei REST halt oft gerne HTTP Basic-Auth verwendet, aber so wirklich kann ich mich nicht mit dem Gedanken anfreunden, die Credentials bei jedem Request im Klartext mitzuschicken.


Also nochmal ganz Grundsätzlich: Ich hab wirklich kein Problem damit, wenn das hier nicht super "ReSTig" wird. Hauptsache es ist einfach und funktioniert.

Gruß,
Daniel

Ist echt faszinierend zu lesen - obwohl ich genauso viel verstehen würde, wenn ihr hebräische Weihnachtslieder rückwärts rezitieren würdet !!!