POST an OData Service mit PHP Klasse

[1UnitedPower]

Hakuna matata!

Sowohl der JSON-Parser als auch der XML-Parser, die ich dir gezeigt habe, können Datenstreams on-the-fly parsen. Jetzt schmeckt dir die Implementation nicht?

Siehe meine erste Anmwerkung zu diesem Thema: Die OData-Entwickler erfinden das Rad neu. Mit wenigen Zeilen Perl kannst Du ganze Datenbanken via HTTP übertragen. Diesbez. Serializer und Low-Level-HTTP-Client gibt es seit Jahren.

Wir versuchen doch zu klären, was an OData unprofessionell ist. Einer deiner Kritikpunkte war, dass die verwendeten Austauschformate (JSON und XML) nicht geparst werden können, bevor alle Daten vorliegen. Ich habe dir anhand von zwei Bibliotheken bewiesen, dass du damit falsch liegst. Dieser Kritikpunkt dürfte sich also erledigt haben.

Ein anderer Kritikpunkt war, dass man in XML und JSON keine Mediendateien einbetten kann. Auch das ist faktisch falsch. Davon abgesehen ist es sowieso keine gute Idee große Mediendateien in Austauschformate einzubetten. Das haben wir alles schon ausdiskutiert.

Jetzt bringst du einen neuen Kritikpunkt ins Spiel, und erklärst dass man mit Perl mit wenigen Zeilen Code ganze Datenbanken übertragen kann. Und dazu kann ich nur sagen, das ist toll, aber das ist eben keine Anforderung, die man mit einem REST-Service zu erfüllen versucht. REST-Services sollen eine einfache und konsistente API zur Verfügung stellen, um die CRUD-Operationen auf einem entfernten Datenbanksystem auszuführen. Replikation ist ein anderes Thema. Ein Service-Provider könnte Replikation intern implementieren, um zum Beispiel Load-Balancing oder Ausfallsicherheit zu garantieren. Das ist aber wie gesagt eine internes Implementations-Detail und muss nicht über die REST-API nach außen getragen werden. Im übrigen ist das reine Kopieren der Datenbank keine besonders klevere Lösung für Replikation. Ich kann also auch in diesem Punkt nicht erkennen, was an OData "laienhaft zusammengeschustert" sein soll.

Bytes ohne Angabe über die Kodierung sind wertlos.

Bytes kennen überhaupt keine Kodierung.

Lies den Satz bitte nochmal. Ich habe nie gesagt Bytes kennen eine Kodierung. Ich sagte Bytesequenzen ohne eine Angabe über ihre Kodierung sind wertlos. Die Daten erhalten erst eine Semantik, wenn man dazu eine Kodierung angibt.

Wenn ein Webservice ein Datenaustauschformat unterstützen will, sei es XML, JSON oder dein selbstgestricktes hotti-eav-binär-Format, dann muss auf der serverseite also ein Kodierer/Serialisierer existieren. Auf der clientseite muss ein Dekodierer/Deserialisierer/Parser existieren.

Es gibt Perl-Versionen, da ist der im Core mitgelieferte Serializer nicht kompatibel.

Wozu soll welcher Serializer nicht kompatibel sein?

Für mich kein Grund, auf XML umzusteigen, ein eigener Serializer für zyklische Strukturen ist denkbar einfach gestrickt.

Das mag alles sein, aber soll sich denn wirklich jeder Entwickler, der einen REST-Service konsumieren will, selber einen Deserializer/Parser bauen? Kann man als REST-Service-Provider wirklich von seinen Benutzern verlangen, dass sie ein neues, total unbekanntes Datenformat lernen? Das wäre wirklich unprofessionell. Es ist doch tausend mal klüger auf erprobte und weit verbreitete Formate zu setzen.

Für JSON und XML sind sowohl Kodierer als auch Dekodierer weit verbreitet. Für dein benutzerdefiniertes Format gibt es, außer deiner eigenen Implementation, keine weitere Bibliotheken.

Es gibt sogar in Sachen Serializer einige Neuentwicklungen auf CPAN.

Da du CPAN schon selber anführst, such doch mal nach JSON oder XML. Das spricht doch wieder nur für diese beiden Formate.

Ich wäre kein Entwickler, wenn ich bisherige Standards und auch eigene Entwicklungen nicht kritisch betrachten würde.

Ich lese mir gerne Kritik durch, deswegen habe ich ja auch nochmal gezielt nachgefragt, worin deine negative Bewertung begründet ist. In diesem Fall hast du dich aber mit deiner Kritik geirrt, denn wir konnten ja objektiv nachvollziehen, dass sie auf falschen Annahmen und Unwissen beruht. Das ist alles kein Beinbruch, es ja tut niemanden weh.

Darüber hinaus war es in der Geschichte schon immer so, dass 'Standards' nicht unbedingt den neuesten Stand der Entwicklung repräsentieren.

Das ist kein Argument sich generell gegen Standards oder insbesondere gegen OData zu wenden.