Menu

Codici di risposta API Rest e tipi di richieste di riposo

  • Principale
  • Altro
  • Codici di risposta API Rest e tipi di richieste di riposo

rest api response codes

Prova Il Nostro Strumento Per Eliminare I Problemi

In questo tutorial, impareremo a conoscere diversi codici di risposta REST, tipi di richieste REST e alcune best practice da seguire :

Nel tutorial precedente, Architettura e vincoli dell'API REST, abbiamo imparato a conoscere i servizi Web, l'architettura REST, POSTMAN, ecc.

Potremmo fare riferimento al primo tutorial dell'API REST per ulteriori informazioni su questo.

Ogni volta che si cerca una parola o una frase in un motore di ricerca, il motore di ricerca invia la richiesta al server web. Il server web restituisce un codice di risposta a tre cifre che indica lo stato della richiesta.

Diversi tipi di codici di risposta e richieste di riposo

Cosa imparerai:

Codici di risposta API Rest

Di seguito sono riportati alcuni codici di risposta di esempio che normalmente vedremo durante l'esecuzione di test API REST su POSTMAN o su qualsiasi client API REST.

# 1) Serie 100
Queste sono risposte temporanee

  • 100 Continua
  • 101 Passaggio da un protocollo all'altro
  • 102 Elaborazione

# 2) Serie 200
Il client accetta la richiesta, essendo elaborata correttamente sul server.

controllo dei collegamenti interrotti di strumenti per i webmaster di Google
  • 200 - OK
  • 201 - Creato
  • 202 - Accettato
  • 203 - Informazioni non autorevoli
  • 204 - Nessun contenuto
  • 205 - Reimposta contenuto
  • 206 - Contenuto parziale
  • 207 - Multi-stato
  • 208 - Già segnalato
  • 226 - IM usato

# 3) Serie 300
La maggior parte dei codici relativi a questa serie sono per il reindirizzamento URL.

  • 300 - Scelte multiple
  • 301 - Spostato in modo permanente
  • 302 - Trovato
  • 303 - Controlla altro
  • 304 - Non modificato
  • 305 - Usa proxy
  • 306 - Cambia proxy
  • 307 - Reindirizzamento temporaneo
  • 308 - Reindirizzamento permanente

# 4) Serie 400
Questi sono specifici per l'errore lato client.

  • 400 - Cattiva richiesta
  • 401 - Non autorizzato
  • 402 - Pagamento richiesto
  • 403 - Proibito
  • 404 non trovato
  • 405 - Metodo non consentito
  • 406 - Non accettabile
  • 407 - Autenticazione proxy richiesta
  • 408 - Timeout richiesta
  • 409 - Conflitto
  • 410 - Andato
  • 411 - Lunghezza richiesta
  • 412 - Precondizione non riuscita
  • 413 - Carico utile troppo grande
  • 414 - URI troppo lungo
  • 415 - Tipo di supporto non supportato
  • 416 - Gamma non soddisfacente
  • 417 - Aspettativa fallita
  • 418 - Sono una teiera
  • 421 - Richiesta mal indirizzata
  • 422 - Entità non elaborabile
  • 423 - Bloccato
  • 424 - Dipendenza non riuscita
  • 426 - Aggiornamento richiesto
  • 428 - Presupposto richiesto
  • 429 - Troppe richieste
  • 431 - Campi intestazione richiesta troppo grandi
  • 451 - Non disponibile per motivi legali

# 5) Serie 500
Questi sono specifici per l'errore lato server.

  • 500 - Errore interno del server
  • 501 - Non implementato
  • errore di connessione 502 Bad Gateway
  • 503 servizio non disponibile
  • 504 Gateway Time-out
  • 505 - Versione HTTP non supportata
  • 506 - La variante negozia anche
  • 507 - Memoria insufficiente
  • 508 - Rilevato loop
  • 510 - Non esteso
  • 511 - Autenticazione di rete richiesta

Oltre a questo, esistono diversi codici diversi, ma questi ci devieranno dalla nostra discussione attuale.

Diversi tipi di richieste REST

Qui discuteremo ogni metodo dell'API REST insieme alle raccolte.

MetodoDescrizione
PATCHMolto simile a put ma è più simile a una piccola manipolazione del contenuto delle risorse
OTTENERERecupera riga di stato, corpo della risposta, intestazione ecc.
CAPOUguale a GET, ma recupera solo la riga di stato e la sezione di intestazione
INVIAREEseguire la richiesta utilizzando il payload della richiesta principalmente nella creazione di un record sul server
METTEREUtile nella manipolazione / aggiornamento della risorsa utilizzando il payload della richiesta
ELIMINAElimina le informazioni relative alla risorsa di destinazione.
OPZIONIDescrivi le opzioni di comunicazione per la risorsa di destinazione

Nota: Esistono così tanti metodi che possiamo fare utilizzando POSTMAN, ma discuteremo solo i seguenti metodi utilizzando POSTMAN.

Useremo un URL fittizio per dimostrare http://jsonplaceholder.typicode.com . Questo URL ci darà le risposte desiderate ma non ci sarà alcuna creazione o modifica nel server.

# 1) OTTIENI

Parametri della richiesta:
Metodo: GET
Richiedi URI: http://jsonplaceholder.typicode.com/posts
Parametro di query: id = 3;

Risposta ricevuta:
Codice stato risposta: 200 OK

Corpo di risposta :

miglior strumento di pulizia per PC

Corpo di risposta

# 2) TESTA

Parametri della richiesta:
Metodo: TESTA
Richiedi URI: http://jsonplaceholder.typicode.com/posts

CAPO

# 3) POST

INVIARE

# 4) Metti

METTERE

ELIMINA

# 5) OPZIONI

Parametri della richiesta:
Metodo: OPZIONI
Richiedi URI: http://jsonplaceholder.typicode.com/
Intestazioni: tipo di contenuto = applicazione / JSON

OPZIONI

# 6) PATCH

PATCH

Best practice durante la convalida di un'API REST

# 1) Operazioni CRUD

Consiste in almeno 4 metodi forniti e dovrebbe funzionare nell'API Web.
GET, POST, PUT e DELETE.

# 2) Gestione degli errori

Possibili suggerimenti per i consumatori API sull'errore e sul motivo per cui si è verificato. Dovrebbe inoltre fornire messaggi di errore di livello granulare.

# 3) Controllo delle versioni delle API

Utilizza la lettera 'v' nell'URL per indicare la versione dell'API. Per esempio-

http://restapi.com/api/v3/passed/319

Parametro aggiuntivo alla fine dell'URL

http://restapi.com/api/user/invaiiduser?v=6.0

# 4) Filtraggio

Consentendo all'utente di specificare, selezionare i dati desiderati invece di fornirli tutti in una volta.
/ contact / sam? nome, età, designazione, ufficio
/ contatti? limite = 25 & offset = 20

# 5) Sicurezza

Timestamp in ogni richiesta e risposta API. Uso di access_token per assicurarsi che l'API venga richiamata dalle parti di fiducia.

come usare eclipse per c

# 6) Analisi

Avere Analytics nella tua API REST ti darà una buona visione dell'API sotto test, specialmente quando il numero di record recuperati è molto alto.

# 7) Documentazione

Deve essere fornita una documentazione adeguata in modo che i consumatori di API possano utilizzarla e utilizzare i servizi in modo efficace.

# 8) Struttura dell'URL

La struttura dell'URL dovrebbe rimanere semplice e un utente dovrebbe essere in grado di leggere facilmente il nome di dominio su di esso.

Per esempio , https://api.testdomain.com.

Anche le operazioni da eseguire tramite l'API Rest dovrebbero essere molto facili da comprendere ed eseguire.

Ad esempio, per un client di posta elettronica:

OTTENERE: read / inbox / messages - Recupera l'elenco di tutti i messaggi in Inbox
OTTENERE: read / inbox / messages / 10 - Legge 10thmessaggio nella posta in arrivo
INVIARE: create / inbox / folders - Crea una nuova cartella in inbox
ELIMINA: Elimina / spam / messaggi - Elimina tutti i messaggi nella cartella spam
METTERE: cartelle / posta in arrivo / sottocartella - Aggiorna le informazioni relative alla sottocartella in Posta in arrivo.

Conclusione

Molte organizzazioni preferiscono implementare l'API Web REST poiché è molto facile da implementare, ha standard e regole minori da seguire, di facile accesso, leggera e di facile comprensione. POSTMAN ha i suoi vantaggi se utilizzato con l'API RESTful grazie alla sua interfaccia utente user-friendly, facilità d'uso e test, tasso di risposta più veloce e nuova funzione RUNNER.

Nel prossimo tutorial di questa serie di tutorial sull'API Rest, automatizzeremo i casi di test che abbiamo eseguito manualmente.

Lettura consigliata

^