Buona pratica per il codice di stato restituito dall'API restful durante la convalida di un token

Questo dipende dallo scopo dell'API.

Se lo scopo è la convalida dei token, il ritorno di 200 OK per le richieste riuscite sembra ragionevole. Un errore 4xx significherebbe che l' utilizzo dell'API di convalida è errato, non che il token non è valido.

Le cose sono diverse se il token gestisce l'accesso a questa API. In tal caso, non è necessario un endpoint per verificare se il token è valido. Il back-end dovrebbe controllare il token di accesso sulla richiesta ogni . Quindi, quando una richiesta non riesce perché il token non è valido, mi aspetterei una risposta Non Autorizzata.

Ricorda che le API REST usano HTTP come transport . I dati effettivi della tua API non sono espressi a livello HTTP, ma nei corpi delle richieste e delle risposte. Le intestazioni e i codici di stato HTTP possono essere utilizzati per metadati, autenticazione e messaggi di errore fuori banda.

Esiste un'analogia con i linguaggi di programmazione qui: una chiamata API è simile a una chiamata di metodo. La risposta contiene un valore di ritorno - il corpo della risposta. Ma se la risposta HTTP ha uno stato 4xx o 5xx, è come se il metodo avesse generato un'eccezione e non fosse ritornato normalmente.

Quindi, la convalida del token: dovrebbe restituire vero / falso come risultato (una risposta di 200 con un corpo contenente quei dati), o non restituire nulla o generare un'eccezione (risposta 2xx contro risposta 4xx)?

Hai codici di stato, dovresti usarli:)

Per me lo sviluppatore non ha progettato correttamente le API, poiché avrebbe dovuto utilizzare i codici di stato come suggerito.

Quindi se la richiesta ha un:

• Token valido :
  • Codice di stato: 200 ;
  • Corpo: non necessario;
• Token malformato (o mancante) :
  • Codice di stato: 400 ;
  • Corpo: messaggio JSON che fornisce informazioni su ciò che è sbagliato nell'input. {"errno": X, "error": "<error-message>"} ;
• Token valido ma non autorizzato
  • Codice di stato: 401 ;
  • Corpo: non necessario.

Come puoi vedere, un corpo JSON non è sempre necessario, un'API REST non dovrebbe basarsi solo sui corpi JSON, ma utilizzare l'intera semantica del protocollo HTTP (s).

Per informazioni sui codici di stato, consulta qui e here .

@AilurusFulgens ha suggerito questo RFC . È molto utile chiarire come utilizzare i corpi JSON con il codice di stato 4xx .

In breve:

• 2xx : vengono utilizzati quando una richiesta ha esito positivo;
• 3xx : vengono utilizzati per identificare un reindirizzamento;
• 4xx : vengono utilizzati per fornire informazioni su un problema del client con la richiesta;
• 5xx : vengono utilizzati per fornire informazioni su un problema del server con la richiesta;