Datenaustausch oder API?

[Rolf b]

@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