Fehlercodes

Im Folgenden finden Sie eine Liste der REST-API-Fehlercodes und eine Erläuterung, wie Fehler an Anwendungen zurückgegeben werden.

Handhabung und Protokollierung von Ausnahmen

Bei der Entwicklung für Marketo ist es wichtig, dass Anforderungen und Antworten protokolliert werden, wenn eine unerwartete Ausnahme auftritt. Während bestimmte Arten von Ausnahmen, wie z. B. die abgelaufene Authentifizierung, sicher durch eine erneute Authentifizierung verarbeitet werden können, erfordern andere möglicherweise Supportinteraktionen, und Anfragen und Antworten werden in diesem Szenario immer angefordert.

Fehlertypen

Die Marketo REST-API kann im Normalbetrieb drei verschiedene Fehlertypen zurückgeben:

Für die Fehlertypen "Response-Level"und "Record-Level"wird ein HTTP-Statuscode von 200 zurückgegeben. Bei allen Fehlertypen sollte der HTTP-Vernunftausdruck nicht ausgewertet werden, da er optional ist und geändert werden kann.

Fehler auf HTTP-Ebene

Unter normalen Betriebsbedingungen sollte Marketo nur zwei HTTP-Status-Code-Fehler zurückgeben: 413 Request Entity Too Large und 414 Request URI Too Long. Diese sind beide durch Auffangen des Fehlers, Ändern der Anforderung und Wiederholen wiederherstellbar, aber mit intelligenten Kodierungspraktiken sollten Sie diese niemals in der Wildnis finden.

Marketo gibt 413 zurück, wenn die Anfrage-Payload 1 MB oder im Fall von Import-Lead 10 MB überschreitet. In den meisten Szenarien ist es unwahrscheinlich, dass diese Beschränkungen erreicht werden. Wenn Sie jedoch eine Überprüfung der Anforderungsgröße vornehmen und Datensätze verschieben, wodurch die Beschränkung auf eine neue Anforderung überschritten wird, sollten keine Umstände mehr möglich sein, die dazu führen, dass dieser Fehler von allen Endpunkten zurückgegeben wird.

414 wird zurückgegeben, wenn der URI einer GET-Anfrage 8 KB überschreitet. Um dies zu vermeiden, prüfen Sie anhand der Länge Ihrer Abfragezeichenfolge, ob sie diesen Grenzwert überschreitet. Wenn Ihre Anforderung in eine POST-Methode geändert wird, geben Sie Ihre Abfragezeichenfolge als Anfrageinhalt mit dem zusätzlichen Parameter _method=GET ein. Dadurch wird die Beschränkung für URIs vergessen. In den meisten Fällen ist es selten, diese Grenze zu erreichen, aber sie kommt eher häufig vor, wenn große Mengen von Datensätzen mit langen individuellen Filterwerten wie einer GUID abgerufen werden.
Der Endpunkt Identität kann einen Fehler "401 Unauthorized"zurückgeben. Dies liegt normalerweise an einer ungültigen Client-ID oder einem ungültigen Client-Geheimnis. Fehlercodes auf HTTP-Ebene

Fehler auf Antwortebene

Fehler auf Antwortebene sind vorhanden, wenn der Parameter success der Antwort auf "false"gesetzt ist, und sind wie folgt strukturiert:

{
    "requestId": "e42b#14272d07d78",
    "success": false,
    "errors": [
        {
            "code": "601",
            "message": "Unauthorized"
        }
    ]
}

Jedes Objekt im Array "errors"hat zwei Mitglieder, code, die eine zitierte Ganzzahl von 601 bis 799 und eine message sind, die den Klartext-Grund für den Fehler angibt. 6xx-Codes weisen immer darauf hin, dass eine Anfrage vollständig fehlgeschlagen ist und nicht ausgeführt wurde. Ein Beispiel ist ein 601, "Zugriffstoken ungültig", das durch erneutes Authentifizieren und Übergeben des neuen Zugriffstokens mit der Anfrage abgerufen werden kann. 7xx-Fehler weisen darauf hin, dass die Anfrage fehlgeschlagen ist, entweder weil keine Daten zurückgegeben wurden oder die Anfrage falsch parametrisiert wurde, z. B. weil ein ungültiges Datum angegeben wurde oder ein erforderlicher Parameter fehlt.

Fehlercodes auf Antwortebene

Ein API-Aufruf, der diesen Antwort-Code zurückgibt, wird nicht mit Ihrem täglichen Kontingent oder Ihrem Ratenlimit gezählt.

Record Level record_level_errors

Fehler auf Datensatzebene zeigen an, dass ein Vorgang für einen einzelnen Datensatz nicht abgeschlossen werden konnte, die Anfrage selbst jedoch gültig war. Eine Antwort mit Fehlern auf Datensatzebene folgt diesem Muster:

Antwort

{
   "requestId":"e42b#14272d07d78",
   "success":true,
   "result":[
      {
         "id":50,
         "status":"created"
      },
      {
         "id":51,
         "status":"created"
      },
      {
         "status":"skipped",
         "reasons":[
            {
               "code":"1005",
               "message":"Lead already exists"
            }
         ]
      }
   ]
}

Datensätze, die im Ergebnis-Array von Aufrufen enthalten sind, werden auf die gleiche Weise wie das Eingabe-Array einer Anforderung sortiert.
Jeder Datensatz in einer erfolgreichen Anfrage kann einzeln erfolgreich sein oder fehlschlagen, was durch das Statusfeld jedes Datensatzes im Ergebnisarray einer Antwort angegeben wird. Das "status"-Feld dieser Datensätze wird "übersprungen" und ein "reasons"-Array ist vorhanden. Jeder Grund enthält ein "code"-Mitglied und ein "message"-Mitglied. Der Code ist immer 1xxx und die Meldung zeigt an, warum der Datensatz übersprungen wurde. Ein Beispiel wäre, wenn für eine SynchronisierungsLeads-Anfrage "action"auf "createOnly"gesetzt ist, aber für einen der Schlüssel in den gesendeten Datensätzen bereits ein Lead vorhanden ist. In diesem Fall wird der Code 1005 zurückgegeben und die Meldung "Lead ist bereits vorhanden"wie oben dargestellt angezeigt.

Fehlercodes auf Datensatzebene