Codici errore
Di seguito sono riportati gli elenchi dei codici di errore REST API e una spiegazione di come gli errori vengono restituiti alle applicazioni.
Gestione e registrazione delle eccezioni
Durante lo sviluppo per Marketo, è importante che le richieste e le risposte vengano registrate quando si verifica un’eccezione imprevista. Mentre alcuni tipi di eccezioni, ad esempio l’autenticazione scaduta, possono essere gestiti in modo sicuro tramite la riautenticazione, altri possono richiedere interazioni di supporto e in questo caso le richieste e le risposte verranno sempre richieste.
Tipi di errore
L’API REST di Marketo può restituire tre diversi tipi di errori in condizioni operative normali:
- Livello HTTP: questi errori sono indicati da un codice
4xx
. - Response-Level: questi errori sono inclusi nell’array "errors" della risposta JSON.
- Record-Level: questi errori sono inclusi nell’array "result" della risposta JSON e sono indicati su base record individuale con il campo "status" e l’array "reason".
Per i tipi di errore a livello di risposta e di record, viene restituito il codice di stato HTTP 200. Per tutti i tipi di errore, la frase relativa al motivo HTTP non deve essere valutata in quanto è facoltativa e soggetta a modifiche.
Errori a livello HTTP
In circostanze operative normali, Marketo dovrebbe restituire solo due errori del codice di stato HTTP, 413 Request Entity Too Large
e 414 Request URI Too Long
. Entrambi possono essere recuperati recuperando l’errore, modificando la richiesta e riprovando, ma con le pratiche di codifica intelligente non dovresti mai incontrarli in modo selvaggio.
Marketo restituirà 413 se il payload della richiesta supera 1 MB, o 10 MB in caso di lead di importazione. Nella maggior parte degli scenari è improbabile che questi limiti vengano raggiunti, ma l’aggiunta di un controllo alle dimensioni della richiesta e lo spostamento di eventuali record, che causano il superamento del limite a una nuova richiesta, dovrebbe evitare qualsiasi circostanza che porti alla restituzione di questo errore da parte di qualsiasi endpoint.
414 verrà restituito quando l’URI di una richiesta GET supera gli 8 KB. Per evitarlo, confrontalo con la lunghezza della stringa di query per vedere se supera questo limite. Se la richiesta viene modificata in un metodo POST, immettere la stringa di query come corpo della richiesta con il parametro aggiuntivo _method=GET
. In questo modo viene superata la limitazione sugli URI. È raro che questo limite venga raggiunto nella maggior parte dei casi, ma è piuttosto comune quando si recuperano grandi batch di record con valori di filtro singoli lunghi, ad esempio un GUID.
L'endpoint Identity può restituire un errore 401 Unauthorized. Ciò è in genere dovuto a un ID client non valido o a un segreto client non valido. Codici di errore a livello HTTP
Errori a livello di risposta
Gli errori a livello di risposta sono presenti quando il parametro success
della risposta è impostato su false e sono strutturati nel modo seguente:
{
"requestId": "e42b#14272d07d78",
"success": false,
"errors": [
{
"code": "601",
"message": "Unauthorized"
}
]
}
Ogni oggetto nell'array "errors" ha due membri, code
, che è un numero intero tra 601 e 799 e un message
che fornisce il motivo plaintext dell'errore. I codici 6xx indicano sempre che una richiesta non è riuscita completamente e non è stata eseguita. Un esempio è un 601, "Token di accesso non valido", che è recuperabile autenticando nuovamente e passando il nuovo token di accesso con la richiesta. Gli errori 7xx indicano che la richiesta non è riuscita perché non sono stati restituiti dati o perché la richiesta non era parametrizzata correttamente, ad esempio includendo una data non valida o mancando un parametro obbligatorio.
Codici di errore a livello di risposta
Una chiamata API che restituisce questo codice di risposta non viene conteggiata rispetto alla quota giornaliera o al limite di tariffa.
- È stata specificata una data con formato non corretto
- È stato specificato un ID di contenuto dinamico non valido
La chiamata non può essere soddisfatta perché viola il requisito di creare o aggiornare una risorsa, ad esempio se si tenta di creare un messaggio e-mail senza un modello. È inoltre possibile ricevere questo errore quando si tenta di:
- Recupera il contenuto per le pagine di destinazione che contengono contenuti social.
- Clona un programma che contiene alcuni tipi di risorse (vedi Clone programma per ulteriori informazioni).
- Approva una risorsa senza bozza (cioè che è già stata approvata).
Record-Level record_level_errors
Gli errori a livello di record indicano che non è stato possibile completare un'operazione per un singolo record, ma la richiesta stessa era valida. Una risposta con errori a livello di record segue questo schema:
Risposta
{
"requestId":"e42b#14272d07d78",
"success":true,
"result":[
{
"id":50,
"status":"created"
},
{
"id":51,
"status":"created"
},
{
"status":"skipped",
"reasons":[
{
"code":"1005",
"message":"Lead already exists"
}
]
}
]
}
I record inclusi nell’array di risultati delle chiamate vengono ordinati nello stesso modo dell’array di input di una richiesta.
Ogni record in una richiesta corretta può avere esito positivo o negativo su base individuale, indicato dal campo di stato di ogni record incluso nella matrice dei risultati di una risposta. Il campo "status" di questi record verrà "ignorato" ed è presente un array "reason". Ogni motivo contiene un membro "code" e un membro "message". Il codice è sempre 1xxx e il messaggio indica il motivo per cui il record è stato ignorato. Un esempio potrebbe essere un caso in cui una richiesta di sincronizzazione dei lead ha "action" impostato su "createOnly", ma esiste già un lead per una delle chiavi nei record inviati. Questo caso restituisce il codice 1005 e un messaggio di "Lead esiste già" come mostrato sopra.