HTTP-Antwortheader für eine eindeutige Anforderungs-ID für den REST-Service

8

Für unseren REST-Service möchte ich bei jeder Antwort eine eindeutige Anforderungs-ID zurücksenden. nützlich zum Debuggen interner Projekte, aber auch zum Anbieten von Unterstützung für Dritte, die den Service möglicherweise in Zukunft nutzen.

Ich habe beschlossen, einen Antwortheader zu verwenden, da nicht alle REST-Anforderungen zu einem Antworttext führen müssen (häufig nutzen REST-APIs niedrigerer Ebene nur den Statuscode und die Beschreibung), müssen diese Anforderung jedoch weiterhin zurücksenden ICH WÜRDE.

Ich möchte nach Möglichkeit sicherstellen, dass ich einen HTTP-Antwortheader verwende, der auf diesem Weg wahrscheinlich nicht von Proxys entfernt wird.

Dies könnte sehr wichtig sein, da es sich bei einer großen Anzahl von Clients wahrscheinlich um mobile Geräte handelt, bei denen es sich zwangsläufig um interessante Netzwerktopologien zwischen ihnen und unseren Servern handelt.

Dieselben Dienste werden jedoch wahrscheinlich auch mit ihren eigenen Unternehmensfirewalls / -proxys an andere Unternehmen vermarktet.

Aus diesem Grund habe ich die Idee, einen benutzerdefinierten Antwortheader zu verwenden, zugunsten eines bekannten Headers verworfen.

Mein derzeit bekannter bekannter Header wäre der ETagHeader, aber obwohl er fast richtig ist, ist er nicht ganz - denn ein ETagist für eine Ressource, keine Anfrage (dh zwei separate Anfragen für dieselbe Ressource geben zu Recht dieselbe zurück ETag). Wenn ich das verwende, bedeutet dies außerdem, dass ich für nichts anderes Entity-Tagging durchführen kann.

Hat jemand bessere Ideen?

Aktualisieren

Der Pragma-Header könnte anscheinend verwendet werden, aber ich habe Probleme beim Schreiben in der Asp.Net-WebAPI. Hier ist eine verwandte Frage zu SO .

web-services rest http

— Andras Zoltan
quelle

4

Ich würde einen standardisierten Körper verwenden und nicht den Header verwenden. Beispielsweise kann jeder Body JSON sein und ein ID-Feld enthalten. Solange es plattformübergreifend standardisiert ist, funktioniert es garantiert.

Ich würde keinen benutzerdefinierten Header verwenden, da das Risiko besteht, dass er entfernt wird. Ich würde keinen Standard-Header verwenden, da ich keinen kenne, der perfekt passt (z. B. wird das von Ihnen erwähnte ETag zum Bestimmen von Dateiänderungen und zum Zwischenspeichern von Schlüsseln verwendet.)

— Matt S.
quelle

2

Ja, das ist eine Option. Aber bei einer solchen Antwort fühlt sich etwas hackig an. Stellen Sie sich eine JSON-Operation vor, die eine Zeichenfolge zurückgibt. Jetzt wird ein Typ mit zwei Mitgliedern zurückgegeben, und Kunden müssen mehr arbeiten, um ihre Daten abzurufen. Nicht sehr erholsam! Ich habe einen Header in der Spezifikation gefunden, der es tun könnte, ich poste eine Antwort ...

— Andras Zoltan

Nein, ich habe es nicht getan. Es sieht so aus, als hätte ich die Definition der Spezifikation von "Nachrichtenkopf" als einen bestimmten Kopf und nicht als eine BNF-Regel falsch interpretiert. Hmmm ...

— Andras Zoltan

1

In all meinen Projekten verwende ich strukturierte Daten im Körper, niemals eine einfache Zeichenfolge, da ich in Zukunft häufig neue Daten hinzufügen muss. JSON ist ein Standardansatz, und jQuery macht den Antworttext bei der Rückkehr von AJAX-Aufrufen automatisch zu einem JS-Objekt. Sie können auch alle Ihre Anrufe / Antworten in Ihre eigenen Funktionen einbinden, um die Struktur konsistent zu handhaben.

— Matt S

0

Schauen Sie sich die Richtlinien des Heroku-Teams an. Unter anderem schlagen sie wie Etags eine Request-ID im Header vor. Wir versuchen, die meisten dieser Richtlinien dort umzusetzen, wo sie sinnvoll sind.

Verfolgen Sie Anforderungen mit Anforderungs-IDs

Fügen Sie jeder API-Antwort einen Request-ID-Header hinzu, der mit einem UUID-Wert gefüllt ist. Wenn sowohl der Server als auch der Client diese Werte protokollieren, ist dies hilfreich, um Anforderungen zu verfolgen und zu debuggen.

https://github.com/interagent/http-api-design/blob/master/README.md

— Bronumski
quelle

1

Das Problem mit benutzerdefinierten Headern ist, dass sie von Proxys legitimerweise entfernt werden können. Am Ende habe ich mich für den Pragma-Header entschieden - er dient dazu, einen Mechanismus zum Zurücksenden Ihrer eigenen benutzerdefinierten Daten bereitzustellen, und er sollte nicht standardmäßig von Proxys entfernt werden, es sei denn, ein Infrastruktur-Bod richtet ihn explizit so ein.

— Andras Zoltan