Datenaustausch oder API?
1 0 
Der Martin
1
0 0 0 0 
Auge
-1 0 
dedlfix
-1 0 
Matthias Apsel
0 dedlfix
0 2 
Rolf b
Datenaustausch oder API?
Moin,
Application programming interface
Ich möchte die Positionen meines Kalenders "pur" anbieten, sodass ein Programmierer die Informationen vom Server abrufen und vor der Ausgabe aufbereiten kann.
Aber wie? Als HTML-Schnipsel, das man mit CSS "bändigt"? Möglichkeit 1:
<style>(nur zum Testen)</style>
<div class="position">
<div class="datum">
<div class="wochentag">Dienstag</div>
<div class="tt">23</div>
<div class="mm">08</div>
<div class="jjjj">2016</div>
</div>
<div class="titel">Open Air "im Palmengarten"</div>
...
</div>
Oder eher als CSV-Datei, Möglichkeit 2:
wochentag;tt;mm;jjjj;titel;...
Dienstag;23;08;2016;"Open Air \"im Palmengarten\"";...
oder noch ganz anders?
Linuchs
-
Ich möchte die Positionen meines Kalenders "pur" anbieten, sodass ein Programmierer die Informationen vom Server abrufen und vor der Ausgabe aufbereiten kann. Aber wie?
XML, JSON
-
Hi,
Ich möchte die Positionen meines Kalenders "pur" anbieten, sodass ein Programmierer die Informationen vom Server abrufen und vor der Ausgabe aufbereiten kann.
Aber wie?XML, JSON
die beiden hätte ich auch vorgeschlagen, JSON bevorzugt.
So long,
Martin--
Nothing travels faster than the speed of light with the possible exception of bad news, which obeys its own special laws.
- Douglas Adams, The Hitchhiker's Guide To The Galaxy -
XML, JSON
Das sind sehr gute Ideen (besonders JSON).
Zu API wird das schon, in dem man noch definiert wie man die Abfrage eingrenzt. Google macht mit seinen API nichts anderes.
Ich hätte im Hinblick auf die sehr konkrete Aufgabe noch einen dritten Vorschlag: iCalendar. In einer API könnte man den Typ mit anfordern. Am trickreichsten könnte es sein, sich beim JSON an die Formate und Namen von iCalendar zu halten, dann brauchst Du, ausgehend vom Hash(Array) mit den Daten nur einen "Exporter" für iCalendar zu schreiben, der für JSON ist ja nativ in PHP drin.
Ein ganz nettes Tool um aus iCalendar-daten einen Kalender zu bauen gibt es auch schon...
-
-
-
Hallo Christian,
die heutzutage gängigste Methode wäre JSON.
Ist es so korrekt? http://remso.eu/?VIP=515&LO=json1
Wie werden Anführungszeichen im Text maskiert?
Und gibt es eine PHP-Funktion, die daraus HTML macht?
Linuchs
-
Hallo Linuchs,
die heutzutage gängigste Methode wäre JSON.
Ist es so korrekt? http://remso.eu/?VIP=515&LO=json1
Nein. Das kannst du aber auch sehr einfach selber prüfen: gib
JSON.parse(deinjson)in der Browser-Konsole ein:
Wie werden Anführungszeichen im Text maskiert?
Mit einem Backslash; aber du solltest das lieber PHP machen lassen.
Und gibt es eine PHP-Funktion, die daraus HTML macht?
Nein, aber eine PHP-Funktion, die daraus wieder eine PHP-Datenstruktur macht.
LG,
CK -
Hallo
JSON
… gibt es eine PHP-Funktion, die daraus HTML macht?
Nein. Schon alleine deshalb, weil PHP nicht von sich aus weiß, welche HTML-Elemente du verwenden willst oder gar welche die richtigen sind , kann es diese Funktion nicht geben. Es gibt aber Funktionen, um aus JSON PHP-Variablen zu erstellen, die du bzw. die Kunden deines Dienstes dann auf den gängigen Wegen in die gewünschte HTML-Struktur einfügen können.
Tschö, Auge
--
Wo wir Mängel selbst aufdecken, kann sich kein Gegner einnisten.
Wolfgang Schneidewind *prust*
-
-
-
oder noch ganz anders?
So einfach wie möglich, z.B.:
location=Zicker;title=Feuerwerk%20am%20Bodden;gmt=1471955340
also die Werte URI-Escaped und das (assoziative) Array kann praktisch jeder Parser wiederherstellen. Für die Uhrzeit reicht ein UNIX-Zeitstempel.
-
Tach!
oder noch ganz anders?
So einfach wie möglich, z.B.:
location=Zicker;title=Feuerwerk%20am%20Bodden;gmt=1471955340
also die Werte URI-Escaped und das (assoziative) Array kann praktisch jeder Parser wiederherstellen. Für die Uhrzeit reicht ein UNIX-Zeitstempel.
Einfachheit ist nicht immer nur ein einfaches Datenformat. Wichtiger ist die einfache Verfügbarkeit von Tools. Einfacher in der Handhabung ist das schon genannte JSON, denn einen solchen Parser hat heutzutage fast jedes System eingebaut. In Javascript wäre das Parsen des Querystrings zum Beispiel noch Handarbeit. Zudem kann JSON beliebig verschachtelte Elemente abbilden, was im Querystring nicht vorgesehen ist. Da existieren lediglich proprietäre Lösungen.
dedlfix.
-
Zudem kann JSON beliebig verschachtelte Elemente abbilden, was im Querystring nicht vorgesehen ist.
Das ist genau das Idiotische, was JSON und XML Nutzer gerne als Argument benutzen: Beliebige Schachtelungen.
Ich würd' mal, in Anbetracht der Trivialität dieser Aufgabe, genau dasselbe machen was PayPal u.a. Serviceprovider machen: Nämlich verschiedene Content-Types anbieten und je nach angeforderten Parameter im Request ausgeben, type=json als Beispiel. Ein zweiter Parameter könnte verbose=1 lauten und selbstverständlich wird in der Response auch der richtige Content-Type-Header gesendet.
PS: Eure -- Bewertung zeigt mal wieder eure Unwissenheit. In gewisser Weise widerspiegelt sich das auch draußen bei den Firmen und in den meisten Fällen unnötig verkomplizerter Lösungen ist es ein erheblicher Mangel an Erfahrung. Solche Kollegen bieten dann z.B. unsinnig geschachtelte Datenstrukturen an, die rekursiv durchlaufen werden müssen anstatt die Nutzdaten möglichst einfach wie zweckmäßig zu verpacken.
Und im Zeitalter von Multimedia (gibt's seit über 20 Jahren) sind XML oder JSON sowieso ein Witz.
-
Hallo pl,
Und im Zeitalter von Multimedia (gibt's seit über 20 Jahren) sind XML oder JSON sowieso ein Witz.
Warum?
Bis demnächst
Matthias -
Tach!
Zudem kann JSON beliebig verschachtelte Elemente abbilden, was im Querystring nicht vorgesehen ist.
Das ist genau das Idiotische, was JSON und XML Nutzer gerne als Argument benutzen: Beliebige Schachtelungen.
Was ist daran idiotisch, strukturierte Daten strukturiert zu übermitteln? Warum soll zum Beispiel eine Liste mit Datensätzen, welche (üblicherweise) aus mehreren Einträgen pro Satz bestehen, nicht als zweistufige Struktur übertragen werden? Was wäre denn die (flache) Alternative bezogen auf die gleiche simple Verarbeitung?
list = json_decode(input) foreach item in list process_item(item)Ich würd' mal, in Anbetracht der Trivialität dieser Aufgabe, genau dasselbe machen was PayPal u.a. Serviceprovider machen: Nämlich verschiedene Content-Types anbieten und je nach angeforderten Parameter im Request ausgeben [...]
Kann man machen, aber warum? Die Großen müssen das sozusagen, um ein sehr großes Publikum mit unterschiedlichen Wünschen bedienen zu können. Als kleiner Kalenderanbieter würde ich den Aufwand zunächst nicht haben wollen. JSON reicht für den Anfang. Wenn da wirklich jemand daherkonmt, dessen System nur XML verarbeiten kann, kann man sich ja immer noch überlegen, ob es den Implementierungsaufwand wert ist. In Richtung JSON kann man unter PHP eine Datenstruktur mit einem einzelnen Aufruf einer im Lieferumfang enthaltenen Funktion umwandeln. Für XML muss man selbst was schreiben oder eine externe Lösung bemühen. Das erzeugt neben dem einmaligen Aufwand beim Selberschreiben Folgeaufwand für das eventuelle Anpassen der eigenen Lösung oder Überwachen der Quelle des externen Paketes auf Korrekturen und andere Änderungen. Das muss man sich ja nicht unbedingt ans Bein holen. Einfachheit hört nicht bei Datenstrukturen auf.
Und im Zeitalter von Multimedia (gibt's seit über 20 Jahren) sind XML oder JSON sowieso ein Witz.
Erzähl doch mal, ich möchte auch lachen.
dedlfix.
-
Hallo hotti,
PS: Eure -- Bewertung zeigt mal wieder eure Unwissenheit. In gewisser Weise widerspiegelt sich das auch draußen bei den Firmen und in den meisten Fällen unnötig verkomplizerter Lösungen ist es ein erheblicher Mangel an Erfahrung.
Die Lösung mit json ist sehr einfach, weil es in den meisten Sprachen fertige Funktionen zum lesen und schreiben von JSON gibt. dedlfix hat ja bereits darauf hingewiesen, dass URL escape komplizierter ist.
Solche Kollegen bieten dann z.B. unsinnig geschachtelte Datenstrukturen an, die rekursiv durchlaufen werden müssen anstatt die Nutzdaten möglichst einfach wie zweckmäßig zu verpacken.
Natürlich kann man Datenstrukturen unsinnig tief gestalten. Aber andersherum habe ich es auch oft gesehen, dass eine Datenstruktur zu flach gestaltet wurde, die dann bei späteren Refactorings wieder aufgebrochen werden musste.
Ich versuche mich immer daran zu halten, welche Bedeutung die Datenstruktur für die Domäne (also im Sinne von Domain Driven Design) hat. Und dann gibt es natürliche Strukturen, die sich automatisch ergeben.
Und im Zeitalter von Multimedia (gibt's seit über 20 Jahren) sind XML oder JSON sowieso ein Witz.
Neben XML und JSON fallen mir im wesentlichen nur zwei weitere Formate ein, mit denen (zwischen Computern) in größerem Umfang Daten ausgetauscht werden: protobuf und CSV (wobei letzteres eigentlich nur zum Austausch von Reports in DWH-Systeme) [und proprietäre Lösungen wie die ganzen JMS-Formate mal ausgeklammert].
Was daran ein Witz sein soll, kann ich nicht erkennen.
Viele Grüße, Matti
-
@PL:
Ja. Es wäre sicher ein Witz, ein Bild oder eine Audiodatei per XML oder JSON zu übertragen.
Ich stimme Dir insoweit zu, dass für die Request-Parameter eine URL-Codierung sinnvoll sein kann. Dann kann ich einen GET Request machen (für JSON oder XML im Request müsste ich einen POST machen) und der könnte sogar gecached werden, wenn die URLs und damit die Abfragekriterien gleich sind.
Das FORMAT der Antwort wird dagegen eher nicht in den URL-Parametern codiert. Das wäre nicht sachgerecht. Bei einem HTTP Interface habe ich Request-Header, die genau so etwas aufnehmen können und sollen. Wenn ich also eine JSON Antwort will, dann sende ich einen Accept: application/json Header mit. Wenn ich XML will, schicke ich application/xml, und wenn's mir egal ist, schicke ich beides. Der Server wird mir dann über den Content-Type Header mitteilen, was er daraus gemacht hat (oder Status 406 schicken). Den Antworttyp im URL Parameter anzufordern mag in Ausnahmefällen sinnvoll sein, aber ich glaube, das ist dann eher ein Kniefall vor den API-Konsumenten, die ihren Toolstack nicht im Griff haben.
Und die Antwort? Natürlich ist die Multimedia. Das Medium wird entsprechend der Wünsche des Clients gewählt, die im Accept-Header spezifiziert werden. Wenn der Server eine vorformatierte Darstellung als PNG liefern kann und der Client das im Accept Header wünscht, dann ist die Antwort natürlich ein PNG und die HTTP Response hat einen entsprechenden Content-Type. Oder Status 406, wenn ich unbedingt ein .fif Format haben will.
Allerdings - so langsam sprengt das dann wieder die Grenzen von HTTP, weil ich ja vielleicht noch die Farbtiefe angeben will oder die Grafikgröße, und - schwupps - brauche ich HTTP Custom Header oder habe doch eine Anfrage mit strukturierten Daten. JSON to the rescue - oder ich lasse diesen Typ Anfrage doch lieber sein.
Die meisten APIs sind aber darauf ausgelegt, weiterverarbeitbare Daten zu liefern, und da ist ein Textformat am sinnvollsten, weil man sich da über Encoding, Charset und Sprache per Header austauschen kann. In einem Binärformat müsste man sich noch über Endian, Wortlänge und vieles mehr einigen, das ist zwar MÖGLICH, aber je strikter ein Format vordefiniert ist, um so weniger Fehler sind möglich. Das ist die Stärke von JSON.
Deinem Einwurf zu Unternehmensberatern, die alles unnötig kompliziert machen, stimme ich gerne zu. Die Kollegen wollen schließlich Geld verdienen und unentbehrlich sein. Darum gibt's die Angestellten, die den Unfug begrenzen müssen. Ob es aber ein Zeichen von Unwissenheit oder Erfahrungsmangel ist, wenn man eine Service-Infrastruktur aufbaut und JSON als Standardprotokoll festlegt? Eher nicht.
Gruß Rolf
-
-
-