Wenn ich eine API ausführe und einen Content-Type-Header korrigiere, führt dies zu Problemen für die Kunden?

14

Wir betreiben eine API, die von einigen Leuten verwendet wird. Aufgrund der Ungeschicklichkeit meines Erachtens gibt einer der Endpunkte den falschen Inhaltstyp-Header zurück , jswenn dies der Fall sein sollte json. Meine Frage ist, wenn wir dies durch Tauschen beheben, um den korrekten Wert zurückzugeben, wie schlimm könnte dies die Dinge für unsere bestehenden Kunden durcheinander bringen? Oder anders ausgedrückt: Würden Sie erwarten, dass viele verschiedene HTTP-Client-Bibliotheken schwerwiegende Fehler auslösen, wenn Sie eine solche Änderung sehen?

Wir versuchen zu entscheiden, ob dies eine Änderung ist, die wir einfach vornehmen können, ohne zu viel zu schwitzen, oder wir sollten allen Benutzern sorgfältig eine E-Mail senden und einen mehrjährigen Verfallszeitraum ankündigen ... oder etwas dazwischen.

Es hängt wahrscheinlich ein bisschen davon ab, welche verschiedenen HTTP-Clients verwendet werden, also habe ich mir Benutzeragenten angesehen. Antwort: viele verschiedene! Hier sind einige der Besten:

"okhttp / 3.2.0", "Python-Anfragen / 2.10.0", "Ruby", "Python-Anfragen / 2.7.0", "Mozilla / 5.0", "Java / 1.8.0_91", "Python-Anfragen" /2.4.3 "," okhttp / 3.3.0 "," Lucee "," Dalvik / 2.1.0 "," Google-HTTP-Java-Client / 1.21.0 "," PHP_appname "," NativeHost "," Java /1.7.0_67 "," Apache-HttpClient / UNAVAILABLE "," Dalvik / 1.6.0 "," Web-Sniffer / 1.1.0 "," unirest-objc / 1.1 "

Verschiedene mobile und serverseitige Sprachbibliotheken. Meistens keine Browser mit Javascript, aber einige davon auch.

Die meisten Leute scheinen nicht zu bemerken, dass der Inhaltstyp falsch ist, aber hin und wieder taucht eine neue Support-Anfrage auf, die sich über dieses Problem beschwert. Deshalb möchten wir es gerne beheben.

http http-headers

— Harry Wood
quelle

4

Ich gehe davon aus, dass Clients, die mit einem falschen Content-Type-Header korrekt funktionieren, nicht mehr funktionieren, wenn Sie den richtigen festgelegt haben, aber Sie wissen, was sie über Annahmen sagen. Testen Sie also, teilen Sie Ihre Änderungen im Voraus Ihrer Benutzerbasis mit und / oder verwenden Sie eine zusätzliche Logik, die es Ihnen ermöglicht, bei einem Ausfall eines bestimmten Clients diesen bestimmten Client zu erkennen und weiterhin den falschen Header des Inhaltstyps zurückzugeben (oder umgekehrt: return) die richtige für Kunden, die Support-Tickets erstellen und für aktuelle Benutzer / Benutzeragenten alles auf dem gleichen Stand halten).

— HBruijn

5

obligatorisch xkcd: xkcd.com/1172

— njzk2

Haben Sie Ihre API nicht versioniert?

— Michael Hampton

Wir haben nur eine Hauptversionsnummer für die gesamte API, die wir erst in ein paar Jahren erreichen würden, wenn wir einige größere Umstrukturierungen vornehmen würden. An diesem Punkt würden wir das Problem natürlich beheben, aber ... es scheint, als würden wir das niemals tun. Es ist eine dieser Versionsnummern.

— Harry Wood

30

Wie schlimm könnte es für unsere bestehenden Kunden sein?

Es könnte ihre Schlachtschiffe völlig untergehen lassen, wenn sie Code geschrieben haben, der davon ausgeht, dass dieser Inhaltstyp falsch ist.

Ich würde nicht erwarten, dass die Bibliotheken Fehler auslösen, aber ich gehe davon aus, dass in einigen Fällen das Verhalten strenger Bibliotheken außer Kraft gesetzt wurde, um den falschen MIME-Typ zu behandeln.

Wenn Ihre API irgendwo in einem Anforderungsfeld einen Versions- / Revisionswert enthält, erhöhen Sie diesen, und geben Sie in der neuen Version den richtigen Typ zurück, während Sie in den älteren Versionen weiterhin den falschen Typ zurückgeben. Wenn Sie kein solches Anforderungsfeld haben, ist jetzt ein guter Zeitpunkt, um eines hinzuzufügen.

— Alzee
quelle

6

+1 schon für eine gute Übertreibung

— HBruijn

4

Oft hast du keine Wahl. Kunden, denen ein Ultimatum zum "Aktualisieren oder Verlassen" erteilt wurde, können sich für Letzteres entscheiden, im Prinzip gut, in der Praxis schlecht. Die alte Version kann im Laufe der Zeit eingestellt werden.

— Alzee

3

+1 für die Versionierung der Anfragen, Sie können jedoch auch auf en.wikipedia.org/wiki/Software_versioning nachsehen, um weitere Informationen zu erhalten.

— SBoss

7

@ WinstonEwert: Natürlich lohnt es sich. Die Benutzer geben an, welche API-Version sie verwenden möchten. In der Zeit zwischen der Aktualisierung Ihrer API und der Aktualisierung ihres Programms brennt ihr Programm dann nicht spontan. Wenn Sie dies nicht tun, unterbrechen Sie automatisch jede aktuelle und frühere Version des Codes Ihrer Kunden, wenn Sie Ihre Benutzeroberfläche ändern. Und das ist eine schreckliche Art, einen Dienst zu betreiben.

— Leichtigkeit Rennen mit Monica

1

Dies scheint übrigens ein sehr guter Punkt zu sein: "Ich gehe davon aus, dass in einigen Fällen das Verhalten strenger Bibliotheken außer Kraft gesetzt wurde, um mit dem falschen MIME-Typ umzugehen. " Bibliotheken werden damit einverstanden sein, aber das ist ein Problem. Einige Kunden haben dies möglicherweise proaktiv umgangen, und das Austauschen wird es dann für sie aufheben. Ich frage mich, wie viel davon passiert ist.

— Harry Wood

11

Würden Sie erwarten, dass viele verschiedene HTTP-Client-Bibliotheken bei einer solchen Änderung schwerwiegende Fehler auslösen?

Nein. Jede mir vertraute HTTP-Clientbibliothek ignoriert den Header des Inhaltstyps, es sei denn, der Programmierer liest diesen Header speziell und unternimmt etwas damit. Ich kann mir eine Bibliothek vorstellen, in der der Inhaltstyp: application / json automatisch einen json-Parser auslöst, aber ich kenne keinen Fall, in dem das tatsächlich passiert.

Die meisten Leute scheinen nicht zu bemerken, dass der Inhaltstyp falsch ist, aber hin und wieder taucht eine neue Support-Anfrage auf, die sich über dieses Problem beschwert. Deshalb möchten wir es gerne beheben.

Wie haben sie den falschen Header bemerkt? Es könnte sich lohnen, sich das anzuschauen, denn wenn der falsche Header tatsächlich Probleme verursachte, ignorierten sie es offensichtlich nicht nur und sie könnten Probleme haben, wenn es behoben ist.

— Winston Ewert
quelle

Meine Antwort hat ein Beispiel, wo das tatsächlich passieren würde .

— Briantist

Wenn Sie jQuery verwenden $.ajaxund die dataType:Option nicht angeben , wird der Antworttyp aus dem Content-typeHeader abgeleitet. Wenn dies der application/jsonFall ist , wird es automatisch analysiert, bevor es an den Anrufer weitergeleitet wird.

— Barmar

6

Zu schwer zu sagen, ohne von all Ihren Kunden eine Bestätigung zu erhalten. Ich würde vorschlagen, einen der folgenden beiden Ansätze zu wählen, um Ihre API auf v.Next zu aktualisieren.

Vorhandene API erweitern. Fügen Sie Ihrer API eine Abfragezeichenfolge oder eine andere Variable hinzu, die angibt, dass v.Next verwendet werden soll. Verwenden Sie für alle Anfragen, die diese Variable verwenden, den aktualisierten Inhaltstyp.
Führen Sie eine Staging- oder Pre-Production-Instanz Ihrer API parallel zu Ihrer aktuellen API aus. Es sollte fast identisch mit der Produktion sein. Auch mit dem gleichen Backend. Obwohl dieser die vorgeschlagenen Änderungen für v.Next haben wird.

Teilen Sie Ihren Kunden in beiden Szenarien die Änderungen mit, die Sie vornehmen möchten, sowie das Datum und die Uhrzeit der geplanten Umstellung. Fordern Sie sie auf, rechtzeitig vor dem Zieldatum zu testen, um sicherzustellen, dass keine Betriebsstörungen auftreten.

Stellen Sie sicher, dass Sie über eine spezielle Seite verfügen, auf der die an v.Next vorgenommenen Änderungen aufgeführt sind. Dies sollte in den Mitteilungen an Ihre Kunden enthalten sein. Wenn Sie Korrekturen mit vorhandenen Clients besprochen haben, fügen Sie diese auf dieser Seite hinzu.

Schliesslich sollten Sie die Grenze zwischen übermäßiger Kommunikation mit Ihren Kunden und Spam-Mails überschreiten. Diese Benachrichtigungen können leicht übersehen werden, da unmittelbarere / dringlichere Prioritäten anstehen.

FWIW, wenn die Dinge gerade funktionieren, würde ich mir keine Sorgen machen. Wenn Sie beispielsweise feststellen, dass dies eine erhebliche Sicherheitslücke verursacht, ist dies ein guter Grund, diese Änderung zu verwerfen. Ansonsten würde ich auf etwas Dringenderes warten, um diese Änderung mit aufzunehmen.

— user2320464
quelle

Vielen Dank. Es ist nicht die Antwort, die ich hören wollte, aber vielleicht hast du recht. Wir müssen die Änderung nur sehr vorsichtig einführen. Ist es aber "zu schwer zu sagen"? Ich glaube, ich hatte gehofft, dass einige Leute Erfahrungen mit den wahrscheinlichen Auswirkungen dieser speziellen Art der Änderung von Content-Typ-Headern haben würden (abgesehen von den allgemeineren Punkten zur vorsichtigen Versionierung)

— Harry Wood,

5

Hier ist ein Beispiel für eine Bibliothek (naja, einzelner Befehl), die dadurch kaputt gehen würde:

Das Cmdlet powershell verhält sich Invoke-RestMethodbei JSON anders. Wenn das Ergebnis der Anforderung JSON, XML oder ATOM / RSS ist (und ich denke, dass es auf dem Header basiert), analysiert / deserialisiert es es und gibt native Objekte zurück, ansonsten gibt es die Rohdaten zurück.

Der vorhandene Code würde also so geschrieben werden, dass er sich mit einer Zeichenfolge befasst (möglicherweise, indem er an diese übergeben wird ConvertFrom-Json), und auf einmal würde ein Fehler auftreten.

— Briantist
quelle

blogs.technet.microsoft.com/heyscriptingguy/2013/10/21/… bestätigt die Theorie, dass dies in der Kopfzeile aussieht.

— Winston Ewert

-2

Ich habe zwei Konsequenzen bemerkt:

Einige Client-Bibliotheken verarbeiten die Antwort nicht richtig. Die Antwort gibt beispielsweise eine Zeichenfolge anstelle von json oder einem Array zurück.
Die Komprimierung wird nicht immer angewendet.

— user368565
quelle

Sicherlich ist es derjenige, der die Daten sendet, nicht derjenige, der sie empfängt, der die Komprimierung anwendet?

— TRiG