Strumenti di debug dell'API: le sei schede che apro quando mi si trova un endpoint

Un endpoint di attivazione della licenza su uno dei miei progetti Laravel ha iniziato a rifiutare ogni token che è stato consegnato. non alcuni token. Ogni token, compresi quelli che lo stesso server aveva emesso novanta secondi prima. dicevano i registri token expired. I token non erano scaduti. Ho passato la maggior parte di un sabato convinto che l'orologio sulla scatola fosse andato alla deriva.

non aveva. Il bug era una riga:

if (payload.exp < Date.now()) throw new Error('token expired')

exp in un JWT è bis dall'epoca - RFC 7519 §4.1.4 non è ambiguo al riguardo. Date.now() In JavaScript restituisce millisecondi. Quindi stavo confrontando un numero di dieci cifre con un numero di tredici cifre e i numeri di dieci cifre sono sempre più piccoli. Ogni segno nell'universo era scaduto, per sempre. La soluzione era Date.now() / 1000. la diagnosi è durata otto ore perché non l'ho mai fatto guardo al gettone - ho continuato a rileggere il mio codice, che è l'equivalente di debug della ricerca dei tuoi occhiali mentre li indosso.

Ciò che alla fine ha rotto il ciclo è stato incollare il token in un decoder, leggendo exp: 1748952000, convertendolo in una data e vedendo un timestamp due settimane in futuro. Il token andava bene. Il mio confronto era sbagliato. Trenta secondi di osservazione dei dati hanno battuto otto ore di osservazione del codice.

That's che cosa questa guida è circa Non intelligente filosofia di debug - gli strumenti specifici, noiosi, poco glamour del browser che tengo in un gruppo di schede chiamato & quot; API Debug, & quot; a cosa ognuno è effettivamente a favore, e le modalità di fallimento che catturano Tutto qui gira lato client su Toolz.dev, che conta più di quanto sembri quando la cosa che stai per incollare è un token al portatore di produzione.

tl; dr: Quando un'API si comporta male, smetti di leggere il tuo codice e inizia a leggere il payload. Formatta la risposta con il Formattatore JSON. Rompi il token con il Decoder JWT, non uno strumento generico Base64. piegare exp, iat, e X-RateLimit-Reset in date reali con il Convertitore di timestamp. confrontare una risposta di lavoro con una rotta con il testo Differenza O, meglio, il JSON DIFF. Decodifica la query-string mangling con il codificatore URL. Tutto viene eseguito nel tuo browser: il token non passa mai oltre il cavo.

Perché il debug di un'API si sente molto peggio del codice di debug?

Perché non puoi attraversarlo. Un bug locale ha una traccia dello stack, un debugger e un punto di interruzione. Un bug API ha una stringa. Il server di qualcun altro ha prodotto quella stringa, secondo le regole che conosci solo a metà, e il tuo lavoro è lavorare a ritroso da essa.

che inverte la solita abilità. Il collo di bottiglia non è logica, è leggibilità. Quasi tutti i bug delle API che ho inseguito negli ultimi anni sono stati invisibili fino a quando non ho reso leggibili i dati:

• una risposta JSON minimizzata di 4.000 caratteri che si è rivelata avere "data": null sepolto a profondità sei.
• Un payload Base64 che decodifica in un messaggio di errore che l'API era troppo educata per inserire il codice di stato.
• Un webhook che ha fallito la verifica della firma perché il corpo aveva una nuova riga finale che il mio client HTTP è stato aggiunto in modo utile.
• Un timestamp che era in millisecondi quando i documenti hanno detto secondi. (due volte. aziende diverse.)

Nessuno di questi erano problemi difficili. Tutti loro erano illeggibile problemi. Gli strumenti seguenti esistono per rendere i dati leggibili abbastanza velocemente da notare la cosa che i tuoi occhi sarebbero passati.

Quale strumento per quale sintomo?

Questo è il tavolo che vorrei che qualcuno mi avesse consegnato cinque anni fa. Sintomo a sinistra, prima sposta a destra.

Tutto sotto è la versione lunga di quella tabella.

Come faccio a rendere leggibile una risposta API in dieci secondi?

incollalo nel Formattatore JSON. That's l'intera tecnica, e I' non essere disinvolto: la singola abitudine di debug con la leva più alta che ho è rifiutarsi di farlo ragionare su Un payload che non ho formattato.

Ecco una forma di risposta che ottengo da un fornitore di fatturazione, esattamente come viene fuori dal filo:

{"subscriptions":[{"id":"sub_7f3d8a2b","status":"active","plan":{"id":"pro_annual","interval":"year","amount":9900},"current_period_end":1748952000,"cancel_at_period_end":false}],"has_more":false}

Formattato, it' è un oggetto completamente diverso, non per il parser, ma per me:

{
  "subscriptions": [
    {
      "id": "sub_7f3d8a2b",
      "status": "active",
      "plan": {
        "id": "pro_annual",
        "interval": "year",
        "amount": 9900
      },
      "current_period_end": 1748952000,
      "cancel_at_period_end": false
    }
  ],
  "has_more": false
}

Ora posso vederlo amount è 9900 E non 99.00- it's in cents, che è il singolo bug di integrazione più comune nei pagamenti - e quello current_period_end è un intero a dieci cifre, che significa secondi, il che significa che non lo consegna new Date() direttamente.

La convalida cattura ciò che i tuoi occhi non hanno vinto

La formattazione convalida anche. Un errore di analisi è l'informazione. Gli errori che effettivamente si manifestano in payload reali:

• virgole finali. Legale in JavaScript, illegale in JSON (per RFC 8259). Gli infissi modificati a mano ne sono pieni.
• Citazioni singole. JSON richiede citazioni doppie. str(dict) L'output non è JSON, non importa quanto assomigli.
• chiavi non quotate. Stessa storia: quella' è un oggetto JavaScript letterale, non JSON.
• NaN / Infinity. Alcuni serializzatori li emettono. JSON non ha tali letterali.
• una nata. un segno di ordine byte UTF-8 davanti { Farà rifiutare un parser rigoroso un documento che sembra perfetto sullo schermo.

Se il tuo JSON è valido ma il foggiare è sbagliato, quello's uno strumento diverso - vedere la sezione diff qui sotto.

Perché usare un decoder JWT invece di decodificare il token solo su Base64?

Puoi decodificare un JWT a mano con Base64. L'ho fatto per anni. È una cattiva abitudine, ed ecco perché.

Un JWT (RFC 7519) è di tre blocchi separati da punti: intestazione, carico utile, firma. Ogni pezzo lo è base64urlnon Base64 standard - RFC 4648 §5, l'alfabeto sicuro per gli URL che si scambia +→- e /→_ e di solito lascia cadere il = imbottitura. Alimentalo a un decoder rigoroso standard-base64 e ti darà un errore o ti darà silenziosamente byte di spazzatura. Quindi il metodo della mano significa dividere i punti, ri-riempire e scambiare l'alfabeto, ogni volta, e poi guardare JSON RAW.

la Decoder JWT fa tutto questo in una pasta e, la parte che in realtà fa risparmiare tempo, presenta le affermazioni come affermazioni. Quelli che controllo, in ordine:

• exp (scadenza) e iat (rilasciato a) - entrambi data numerica, cioè bis Dal 1970-01-01 UTC. Questo è il campo che ha mangiato il mio sabato.
• aud (pubblico) - un token coniato per la tua API di staging sarà strutturalmente perfetto e comunque rifiutato da prod.
• iss (emittente) - dopo una migrazione del fornitore di identità, questo è il campo che è cambiato silenziosamente.
• alg nell'intestazione - se dice none, hai un problema di sicurezza, non un problema di debug.

Prendi il segno di esempio canonico che tutti hanno visto:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Intestazione: {"alg":"HS256","typ":"JWT"}. Carico utile: {"sub":"1234567890","name":"John Doe","iat":1516239022}. e iat c'è 2018-01-18T01:30:22Z- che conosci solo eseguendolo attraverso un convertitore timestamp, che è il punto centrale della sezione successiva.

la cosa che un decoder non fa

La decodifica non sta verificando. Chiunque può decodificare un JWT, il payload è codificato, non crittografato. Un decoder ti dice qual è il token reclami, mai se l'affermazione è vera. La verifica della firma avviene sul tuo server con il tuo segreto e nessuno strumento del browser dovrebbe mai essere consegnato quel segreto. Tratta un JWT decodificato nel modo in cui tratti un modulo di presentazione: come un'affermazione da parte di uno sconosciuto.

Come faccio a smettere di sbagliare i timestamp?

Impara a leggere il conteggio delle cifre. Questa è l'abilità di debug più economica in tutto il campo e ci vuole un minuto per imparare.

Dieci cifre significa secondi. Tredici significa millisecondi. Date Costruttore vuole millisecondi; Unix, Python time.time(), vai Unix(), PHP time(), e la maggior parte delle API' exp I campi parlano secondi. Tutto a valle di quella discrepanza è caos.

E il caos è forte in una direzione e silenzioso nell'altra. alimentazione bis ad un parser millisecondo e ottieni 1970 - un bug così evidente che lo risolvi in un minuto Feed millisecondi ad un bis parser e ottieni l'anno 56122. ho controllato: 1708876200000, interpretato come secondi, atterra il 17 febbraio dell'anno 56122. That' è la direzione che spedisce silenziosamente, perché nulla tira - un abbonamento semplicemente non scade mai e nessuno se ne accorge per un quarto.

la Convertitore di timestamp esiste in modo da poterlo sistemare in una pasta invece di discuterne. pasta 1748952000, leggi la data, vai avanti. Incolla il X-RateLimit-Reset Intestazione di cui la tua API si sta lamentando e scopri che hai quattro minuti per aspettare, non quattro ore. Se il timestamp è ingenuo (no Z, nessun offset) e devi ragionare su cosa significa in un'altra regione, il Convertitore di fusi orari è il seguito.

Altre due trappole di timestamp che vale la pena conoscere

Il problema del 2038 è reale e datato. Un contatore di secondi a 32 bit firmato trabocca 2147483647, che è 2038-01-19T03:14:07Z. Qualsiasi sistema che memorizza ancora il tempo in un int a 32 bit con segno - e ce ne sono più nelle colonne del database incorporato e legacy di quanto chiunque voglia ammettere - si rompe allora. Se tu' stai impostando scadenze di lunga durata oggi, sei già in grado di colpire questo.

I timestamp ingenui sono una bugia per omissione. 2026-02-25T14:30:00 senza traino Z E NO +05:30 non è un momento, è un momento in un luogo non specificato. Tratto qualsiasi API che restituisca timestamp ingenui come una segnalazione di bug in attesa di essere archiviata. preferire RFC 3339 (2026-02-25T14:30:00Z), che è il profilo rigoroso e inequivocabile della ISO 8601 che il Web utilizza effettivamente.

Cosa faccio quando "ha funzionato ieri"?

Diffondilo. Don't teorizza: differilo.

Cattura la risposta dall'ambiente di lavoro (o scava l'ultimo buono fuori dai tuoi registri) e la risposta da quello rotto e mettili fianco a fianco. Nove volte su dieci c'è esattamente una differenza e ti sta fissando in cinque secondi.

Per JSON, raggiungere il JSON DIFF Prima del testo diff. analizza entrambi i lati e confronta struttura, che significa chiavi riordinate e diversi rientro don' t si presentano come modifiche - solo quelle reali fanno Un testo diff di due documenti JSON che un server serializzato in un ordine di chiave diverso si illuminerà come un albero di Natale e non ti dirà nulla.

Per tutto ciò che è't JSON - intestazioni, corpi grezzi, file di configurazione, curl output - utilizzare il testo Differenza. La sua specialità è la classe di cambiamento che i tuoi occhi sono fisicamente incapaci di catturare: uno spazio finale, una scheda che è diventata quattro spazi, una linea CRLF che terminava che si intrufolava da una macchina Windows, una citazione riccia che un sito di documentazione sostituiva con uno dritto quando hai copiato l'esempio. Ho scritto un intero pezzo su Perché i confronti di testo eyeballing falliscono, perché una volta mi è costato un'escalation di supporto.

Perché i miei parametri di query continuano ad arrivare rotti?

Perché la codifica URL ha tre o quattro gusti leggermente diversi e lo stack di tutti ne sceglie uno diverso.

I classici, in ordine approssimativo di quanto spesso mi mordono:

• + contro %20. In una stringa di query, + Storicamente significa uno spazio (il application/x-www-form-urlencoded convenzione). In un segmento di percorso, + significa un vantaggio letterale. Quindi una firma Base64 contenente +, inserito in una stringa di query non codificata, arriva con spazi al suo interno e il controllo della firma non riesce. Questo è davvero brutto perché il valore aspetto proprio nei registri.
• Codifica doppia. %2F diventa %252F Perché due livelli del tuo stack lo hanno codificato entrambi. Il sintomo è un parametro che guadagna segni percentuali ogni volta che passa attraverso un proxy.
• un crudo & all'interno di un valore. Divide il tuo parametro in due. presente name=Ben & Jerry è name=Ben più un param misterioso chiamato Jerry.

Incolla l'URL nel codificatore URL e decodificarlo. Se decodificarlo una volta lascia ancora percent-Escage, hai trovato la tua doppia codifica. Questo è l'intero diagnostico.

Come faccio a eseguire il debug di un webhook che non verrà verificato?

Questo è quello che separa "Capisco http" da "i' sono stato di guardia."

Quasi tutti i provider di webhook firmano il carico utile con un HMAC e inseriscono il risultato in un'intestazione. Il tuo compito è calcolare lo stesso HMAC e confrontare. Quando non corrisponde, la firma non è quasi mai il problema. I byte sono il problema. Non stai hashing ciò che hanno HASH.

I soliti sospetti:

1. Hai fatto il brano analizzato e riserializzato. Il tuo framework ha analizzato il JSON in un oggetto, hai chiamato JSON.stringify() su di esso, e ora l'ordine delle chiavi o lo spazio bianco differiscono di un carattere. devi hash il crudo corpo della richiesta, byte come ricevuto. In Express ciò significa catturare il buffer grezzo prima express.json() arriva; in Laravel significa $request->getContent(), no $request->all().
2. una nuova riga in coda. Alcuni clienti ne aggiungono uno. Il fornitore non lo ha fatto.
3. Stai hashing la stringa codificata esadecimale invece dei byte grezzi, o confrontando esagono con base64.
4. set di caratteri. Il corpo ha un carattere multibyte e qualcosa lungo il percorso lo ha transcodificato.

la Generatore di hash è come lo isolino: prendi la stringa del corpo esatta, la hash, confronta con quella che il mio codice ha prodotto per quello che ha pensiero era lo stesso corpo. Se questi due hash differiscono, il mio codice non vede i byte che penso che stia vedendo e il problema non è mai stato la crittografia. (Vale anche la pena sapere: se un fornitore offre ancora firme MD5 o SHA-1, questo è un segnale sull'età della sua piattaforma. SHA-256 è il pavimento ora.)

Cos'altro vive nel gruppo di schede di debug?

Il cast di supporto - meno glamour, si guadagna comunque il suo posto:

• Generatore di UUID- per una pulizia X-Request-ID Ad ogni chiamata di prova, puoi farla scorrere in tre registri di servizi in seguito. Vale la pena sapere che gli UUID hanno ricevuto un aggiornamento delle specifiche: RFC 9562 (2024) obsoleto RFC 4122 e standardizzato uuidv7, che è ordinato nel tempo e quindi molto più affettuoso rispetto all'indice B-Tree del tuo database rispetto a Random V4. Se oggi scegli uno schema di identificazione per un nuovo tavolo, quello è quello su cui continuare. c'è un Ripartizione più lunga delle versioni UUID Se lo vuoi.
• convertitore base64- per Authorization: Basic Intestazioni (RFC 7617: IT&S base64(user:password), e sì, che & #39; codifica s, non sicurezza - TLS è ciò che lo protegge), e per il binario in linea blobs alcune API roba in campi JSON Base64 ti costa ~ 33% dimensione overhead, che è il motivo per un & quot; inaspettatamente grande& quot; payload spesso ha solo un file in esso Il Guida completa di base64 Copre la distinzione Base64URL che fa inciampare le persone.
• Condivisore di yam- perché metà dei miei errori API nell'ultimo anno erano errori API ' t. Si trattava di un errore di indentazione a due spazi in una configurazione CI e l'endpoint non è mai stato distribuito. (YAML ha una modalità di errore più brutta di una build interrotta, però: YAML valido che significa qualcosa che avevi & #39; non intendevo. Ho scritto perché version: 1.10 diventa 1.1 dopo che mi è costato una distribuzione.)
• tester regex- per il momento devi estrarre un ID di richiesta da 900 righe di registro con un modello di cui & #39; non sono sicuro.
• Visualizzatore CSV- per l'endpoint di esportazione di cui è necessario verificare la sanità mentale prima che qualcuno lo importi in produzione.

Importa davvero che questi funzionino nel browser?

Sì, e lo direi anche se non avessi costruito il sito.

Pensa a cosa incolli in uno strumento di debug. Un JWT - che è un Credenziale dal vivo fino alla sua scadenza. Una risposta dell'API di produzione, che è dati del cliente: nomi, e-mail, stati di abbonamento. un corpo di webhook, che può contenere un record di pagamento. un' curl comando con un Authorization intestazione ancora in esso.

Considera ora che uno strumento lato server, per definizione, riceve tutto ciò Non maliziosamente - solo architettonicamente La pasta entra in una richiesta HTTP, colpisce qualcuno's backend, e atterra in qualsiasi registrazione capita di eseguire Anche un operatore scrupolosamente onesto finisce con il tuo token portante in un registro di accesso che non hanno mai avuto intenzione di mantenere.

Gli strumenti su Toolz.dev fanno il lavoro in JavaScript nella tua scheda Nulla viene caricato, perché lì' non c'è nessun posto in cui caricarlo - l'analisi, la decodifica, l'hashing avvengono tutti sulla tua macchina Non fai' non devi credermi sulla parola, nemmeno: apri DevTools, vai alla scheda Rete, incolla un token e guarda una richiesta che non arriva mai. That' ha un audit di trenta secondi e dovresti eseguirlo un po' di Strumento in cui incolla i segreti, il mio incluso. ho scritto Come verificare correttamente uno strumento lato client proprio per questo motivo.

Se la tua organizzazione gestisce i dati personali dell'UE, questo è & #39; t solo igiene - incollare i record dei clienti in un server di terze parti è un'attività di elaborazione, con tutte le pratiche burocratiche GDPR che implica Gli strumenti lato client eludono la domanda non diventando mai un processore.

un flusso di lavoro che si attacca effettivamente

Sei passi, nell'ordine li eseguo quando qualcosa è in fiamme:

1. catturare la risposta grezza. Corpo completo, intestazioni complete, codice di stato. Non la tua app's interpretazione di esso - i byte effettivi. curl -i o la scheda di rete "Copia come ricciolo."
2. Formattalo. Formattatore JSON. Guarda il foggiare Prima di guardare i valori. Il campo di cui hai bisogno è anche presente?
3. Decodifica ogni stringa opaca. gettoni attraverso il Decoder JWT, BLOB BASE64 attraverso il convertitore base64, URL maciullati attraverso il codificatore URL. Le stringhe opache nascondono la risposta sorprendentemente spesso.
4. Trasforma ogni numero che potrebbe essere un'ora in una data. Convertitore di timestamp. Conta prima le cifre.
5. diff contro una risposta nota-buona. JSON DIFF. Se non hai una risposta nota, questo è il tuo segno per iniziare a salvarli.
6. Solo ora vai a leggere il tuo codice. A questo punto di solito si conosce la riga prima di aprire il file.

L'ordine è importante. Il passaggio 6 è il punto in cui iniziavo, ed è per questo che quel sabato ci sono volute otto ore.

Domande frequenti

Quali sono i migliori strumenti gratuiti per il debug delle API?

Per il debug API quotidiano di API hai bisogno di cinque cose: un formattatore e un validatore JSON, un decoder JWT, un convertitore di timestamp Unix, uno strumento diff e un codificatore/decoder URL. Tutti e cinque sono gratuiti su Toolz.dev e vengono eseguiti interamente nel browser. Aggiungi un generatore di hash se lavori con i webhook firmati e un convalidatore yaml se le tue distribuzioni sono basate sulla configurazione.

È sicuro incollare una risposta JWT o API in uno strumento online?

Solo se lo strumento è lato client Un JWT è una credenziale live e una risposta API sono solitamente dati del cliente, quindi uno strumento lato server significa spedire entrambi a un backend stranger's Gli strumenti Toolz.dev elaborano tutto nel tuo browser con JavaScript e non inviano nulla sulla rete: verificalo tu stesso aprendo DevTools' Scheda di rete mentre incolli Esegui lo stesso controllo su qualsiasi strumento che utilizzi con dati sensibili.

Perché il mio JWT dice "scaduto" quando l'ho appena generato?

La causa più comune è una mancata corrispondenza delle unità. la exp L'affermazione è in pochi secondi (RFC 7519 lo definisce come un data numeric), ma JavaScript Date.now() Restituisce millisecondi, quindi confrontarli direttamente fa sì che ogni token sia scaduto. decodifica il token, leggi exp, convertilo in una data reale con un convertitore di timestamp e controlla se è effettivamente in passato prima di toccare il tuo codice di autenticazione.

Come faccio a sapere se un timestamp unix è in secondi o millisecondi?

contare le cifre. Dieci cifre sono secondi, tredici è millisecondo, sedici sono microsecondi. Se una data esce nel 1970, hai alimentato secondi a un parser di millisecondi; se esce nell'anno 56122 hai alimentato millisecondi a un parser di secondi. Il secondo errore è più pericoloso perché nulla genera un errore.

Posso utilizzare questi strumenti per eseguire il debug delle API GraphQL?

si. Le risposte GraphQL sono JSON, quindi il formattatore JSON e il differenziale JSON funzionano invariati e GraphQL utilizza in genere la stessa autenticazione del token al portatore che decodifica con il decoder JWT. L'unica vera differenza è che GraphQL restituisce HTTP 200 con un errors array invece di uno stato non 2xx, quindi formatta sempre il corpo: il guasto è all'interno del carico utile, non nel codice di stato.

Perché la mia verifica della firma del webhook fallisce sempre?

Quasi sempre perché stai hashing diversi byte rispetto al provider. Se il tuo framework ha analizzato il corpo JSON e l'hai riserializzato prima dell'hash, lo spazio bianco o l'ordine chiave sono cambiati e l'HMAC non corrisponderà mai. Hash il corpo della richiesta RAW esattamente come ricevuto e controlla la presenza di una nuova riga finale aggiunta dal tuo client HTTP.

Qual è la differenza tra la codifica Base64 e Base64URL?

Usi standard Base64 (RFC 4648 §4) + e / nel suo alfabeto e tamponi con =. Base64URL (RFC 4648 §5) sostituisce quelli con - e _ e di solito lascia cadere l'imbottitura, quindi il valore è sicuro da inserire in un URL o in un JWT. L'alimentazione dei dati Base64URL a un decoder rigoroso standard-base64 produce un errore o spazzatura, motivo per cui un decoder JWT dedicato batte la decodifica a mano di un token.

Come faccio a eseguire il debug di una risposta non autorizzata 401?

lavorare verso l'esterno dal token. decodificarlo e controllare exp contro il tempo corrente - un token scaduto è la singola causa più comune, ed è invisibile fino a quando non converti il reclamo in una data leggibile Se il token è attivo, controlla il Authorization Intestazione stessa: lo schema deve essere presente e scritto correttamente (Bearer <token>, uno spazio, nessuna citazione) e un token incollato da un terminale spesso porta una nuova riga finale che interrompe la partita. Successivamente, confermare il aud e iss I reclami corrispondono a ciò che l'API si aspetta, poiché un token valido emesso per un pubblico diverso viene rifiutato esattamente come uno cattivo. Solo allora inizia a sospettare il server.

Come faccio a decodificare un JWT senza una libreria?

Un JWT è composto da tre segmenti base64url uniti da punti Dividi sui punti, quindi base64url-decodifica i primi due - l'intestazione e il payload - ed entrambi escono come JSON semplice Il terzo segmento è la firma, e non decodifica in nulla di leggibile perché è byte raw piuttosto che testo Questo conta più di quanto sembri: decodificare un token ti dice cosa sostiene, non se quelle affermazioni sono vere Verificare la firma richiede l'emittente's chiave e appartiene al tuo codice server, mai in uno strumento del browser Leggi i token qui per eseguire il debug; convalidarli nell'applicazione.

Ho ancora bisogno di postino o insonnia se uso questi strumenti?

Sì - risolvono problemi diversi Un client API invia richieste; questi strumenti rendono leggibili le risposte In pratica utilizzo il client per licenziare la richiesta e copiare l'output raw, quindi passare agli strumenti del browser per formattarlo, decodificarlo, convertirlo e diffonderlo Si siedono uno accanto all'altro nel flusso di lavoro anziché sostituirsi l'uno all'altro.