Der Client stellt konsistent Anforderungen mit dem Accept-Header "application / json" und dem Inhaltstyp "application / json".
Ja, dies ist die richtige Vorgehensweise, bedeutet jedoch nicht, dass sich der Anbieter darum kümmert. Ich verstehe Ihre Frustration zwar vollkommen, da ich auch der Meinung bin, dass ein JSON-Service immer eine JSON-Antwort geben sollte, aber es gibt viele Beispiele, bei denen dies nicht der Fall ist.
Während des gesamten Projekts wurde dieselbe Vorgehensweise bei zwei verschiedenen Anbietern und zwei verschiedenen Diensten angewendet. Ich musste rechtfertigen, warum die Dienste geändert werden mussten. Die Anbieter gaben an, dass der Client damit fertig werden sollte, und sogar meine REST-Bibliothek der Wahl wurde in Frage gestellt (RestEasy), da sie dies standardmäßig nicht „out the box“ erledigt.
Nun, ich muss dem Verkäufer zustimmen. Es ist ihr Service und solange sie die speziellen Fälle für die Verwendung klar dokumentieren, kann man nicht wirklich aufzwingen, dass sie es ändern. Dies ist ein Nachteil für sie, da Entwickler ihre API nur langsam einführen. Wenn sie sich anhören, was die Entwickler benötigen, ändern sie dies. Leider gibt es keine Regel, dass sie Standards einhalten müssen.
Die Frage ist, fehlt mir etwas?
Anforderungsheader haben nur dann eine Bedeutung, wenn sie am anderen Ende korrekt unterbrochen werden. Ich weiß, wenn ich eine Web-API mit PHP entwickle, dann zum Teufel mit den Request-Headern. Ich kann mit allem antworten, was ich will. Während ein in IIS mit C # konfigurierter Dienst die Handhabung von Anforderungsheadern, ihres Typs und des Antworttyps erheblich vereinfacht. Dies hat viel mit den Tools zu tun, mit denen der Anbieter die API erstellt hat.
Ich bin ich pedantisch darüber?
Ja und Nein. Ich habe Entwicklerfreunde, die nicht in der Lage wären, daran vorbeizukommen. Sie würden durch das Problem so fixiert und könnten erst dann mit anderen Aufgaben fortfahren, wenn die API so funktioniert, wie sie es erwartet haben. Das ist pedantisch.
Dies ist ein Problem, da der Anbieter "mehr Arbeit" erstellt hat, um Ihre Aufgaben abzuschließen. Das würde jeden frustrieren. Ich weiß, dass ich es sein würde.
Ist es in Ordnung, eine JSON-API zu haben, die in diesem Szenario keinen Anwendungstyp / json für Inhalte hat?
Absolut, aber es ist keine gute Übung.
Ein Client kann dem Server nur mitteilen, welcher Kontexttyp ein requestist. Es kann keinen Inhaltstyp für das erzwingen response. Der Client kann dem Server nur mitteilen, dass er accepteine Sammlung möglicher Inhaltstypen erstellt.
Header-Felddefinitionen
Im Feld Anforderungsheader akzeptieren können bestimmte Medientypen angegeben werden, die für die Antwort akzeptabel sind. Accept-Header können verwendet werden, um anzuzeigen, dass die Anforderung speziell auf einen kleinen Satz gewünschter Typen beschränkt ist, wie im Fall einer Anforderung für ein Inline-Image.
Es ist für einen Client möglich, ein Image von anzufordern image/jpeg, der Server antwortet jedoch mit text/htmlund einem Statuscode, 404ob das Image nicht gefunden wurde. Server können auch falsch reagieren. Es gibt viele Wordpress-Websites, die mit text/htmlund Statuscode 200für nicht gefundene Seiten antworten .
Nun, das ist alles schlechte Praxis seitens des Servers. Ich versuche Ihnen zu sagen, dass dies absolut möglich ist und häufig vorkommt. Die Leute wissen nicht, was sie tun, wenn sie diese Dinge konfigurieren.
Hinweise würden geschätzt. Wie lösen Sie diese Situation aus kommerzieller Sicht?
Ich bin auf dieses Problem bei einigen Projekten gestoßen. Sie postJSON-Daten an den Server und es gibt entweder eine JSON oder HTML-Antwort zurück.
Es ist wirklich keine große Sache zu wissen, welcher Typ in der Antwort war. Wenn das erste Zeichen {oder ist [, können Sie JSON annehmen. Wenn <ja, können Sie von HTML ausgehen. So habe ich es in der Vergangenheit gehandhabt. Manchmal weiß der Programmierer, der die API geschrieben hat, alles über HTTP-Header. Alles kommt als text/htmlAntwort zurück. Wenn Sie Glück haben, haben sie Apache auf Standard konfiguriert, text/plainwas manchmal helfen kann.
Diese Probleme bestehen und werden auch in Zukunft bestehen bleiben. Server-zu-Server-Kommunikation ist bei weitem keine regulierte Aktivität. Es gibt kein Leitungsorgan, das einen Anbieter aus einer Gewerkschaft für einen Server ausschlägt, der schlechte HTTP-Antworten liefert.