Meniu

Coduri de răspuns API Rest și tipuri de cereri de repaus

  • Principal
  • Alte
  • Coduri de răspuns API Rest și tipuri de cereri de repaus

rest api response codes

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

În acest tutorial, vom afla despre diferite coduri de răspuns REST, tipuri de cereri REST și câteva dintre cele mai bune practici care trebuie urmate. :

În tutorialul anterior, REST API Architecture And Constraints, am aflat despre serviciile web, REST Architecture, POSTMAN etc.

Putem consulta primul tutorial API REST pentru mai multe informații despre acest lucru.

Ori de câte ori căutați orice cuvânt sau expresie dintr-un motor de căutare, acesta trimite cererea către serverul de internet. Serverul web returnează un cod de răspuns din trei cifre care indică starea cererii.

Diferite tipuri de coduri de răspuns și cereri de odihnă

Ce veți învăța:

Restul codurilor de răspuns API

Iată câteva exemple de coduri de răspuns pe care le vom vedea în mod normal în timp ce efectuăm testarea REST API pe POSTMAN sau pe orice client REST API.

# 1) Seria 100
Acestea sunt răspunsuri temporare

  • 100 Continuați
  • 101 Comutarea protocoalelor
  • 102 Prelucrare

# 2) Seria 200
Clientul acceptă Cererea, fiind procesat cu succes la server.

cum se deschide un fișier swf în Chrome
  • 200 - OK
  • 201 - Creat
  • 202 - Acceptat
  • 203 - Informații fără autoritate
  • 204 - Fără conținut
  • 205 - Resetați conținutul
  • 206 - Conținut parțial
  • 207 - Multi-Status
  • 208 - Raportat deja
  • 226 - IM folosit

# 3) Seria 300
Majoritatea codurilor legate de această serie sunt pentru redirecționarea adreselor URL.

  • 300 - Opțiuni multiple
  • 301 mutat permanent
  • 302 - Găsit
  • 303 - Bifați Altele
  • 304 - Nemodificat
  • 305 - Utilizați proxy
  • 306 - Comutare proxy
  • 307 - Redirecționare temporară
  • 308 - Redirecționare permanentă

# 4) Seria 400
Acestea sunt specifice erorilor din partea clientului.

  • 400 - Cerere greșită
  • 401 - Neautorizat
  • 402 - Plata necesară
  • 403 Interzis
  • 404 Nu a fost gasit
  • 405 - Metoda nu este permisă
  • 406 - Inacceptabil
  • 407 - Este necesară autentificarea proxy
  • 408 Termen de întrerupere al solicitării
  • 409 - Conflict
  • 410 - S-a dus
  • 411 - Lungime necesară
  • 412 - Precondiția a eșuat
  • 413 - Sarcina utilă prea mare
  • 414 - URI prea lung
  • 415 - Tip media neacceptat
  • 416 - Gama nu este satisfăcătoare
  • 417 - Așteptarea a eșuat
  • 418 - Sunt ceainic
  • 421 - Cerere greșită
  • 422 - Entitate neprocesabilă
  • 423 - Blocat
  • 424 - Dependență eșuată
  • 426 - Actualizare necesară
  • 428 - Condiție prealabilă necesară
  • 429 - Prea multe cereri
  • 431 - Solicitați câmpurile antetului prea mari
  • 451 - Indisponibil din motive legale

# 5) Seria 500
Acestea sunt specifice erorii de la server.

  • 500 Eroare internă a server-ului
  • 501 - Neimplementat
  • 502 Bad Gateway
  • 503 Serviciu Indisponibil
  • 504 - Gateway Timeout
  • 505 - Versiunea HTTP nu este acceptată
  • 506 - Varianta negociază, de asemenea
  • 507 - Stocare insuficientă
  • 508 - Buclă detectată
  • 510 - Nu este extins
  • 511 - Este necesară autentificarea în rețea

În afară de aceasta, există mai multe coduri diferite, dar acestea ne vor abate de la discuția noastră actuală.

Tipuri diferite de cereri de REST

Aici vom discuta despre fiecare metodă a API-ului REST împreună cu colecțiile.

MetodăDescriere
PLASTUREFoarte similar cu put, dar este mai degrabă o manipulare minoră a conținutului resurselor
OBȚINEObțineți linia de stare, corpul de răspuns, antetul etc.
CAPLa fel ca GET, dar numai preluarea liniei de stare și a secțiunii antet
POSTEfectuați solicitarea utilizând sarcina utilă a cererii, în special în crearea unei înregistrări la server
A PUNEUtil în manipularea / actualizarea resursei folosind Solicitare sarcină utilă
ȘTERGEȘterge informațiile referitoare la resursa țintă.
OPȚIUNIDescrieți opțiunile de comunicare pentru resursa țintă

Notă: Există atât de multe metode care există, pe care le putem face folosind POSTMAN, dar vom discuta doar următoarele metode folosind POSTMAN.

Vom folosi o adresă URL falsă pentru a demonstra http://jsonplaceholder.typicode.com . Această adresă URL ne va oferi răspunsurile dorite, dar nu va exista nicio creație, modificare în server.

# 1) OBȚINE

Parametri de solicitare:
Metodă: GET
Solicitați URI: http://jsonplaceholder.typicode.com/posts
Parametru de interogare: id = 3;

Răspuns primit:
Cod de stare de răspuns: 200 OK

Corpul de răspuns :

Corpul de răspuns

# 2) CAP

Parametri de solicitare:
Metoda: CAP
Solicitați URI: http://jsonplaceholder.typicode.com/posts

CAP

# 3) POST

POST

# 4) PUT

A PUNE

ȘTERGE

# 5) OPȚIUNI

Parametri de solicitare:
Metoda: OPȚIUNI
Solicitați URI: http://jsonplaceholder.typicode.com/
Anteturi: Content-type = Application / JSON

OPȚIUNI

# 6) PATCH

PLASTURE

cum să declarați o serie de obiecte în java

Cele mai bune practici în timpul validării unui API REST

# 1) Operațiuni CRUD

Constă din minimum 4 metode furnizate și ar trebui să funcționeze în API-ul web.
GET, POST, PUT și STIRI.

# 2) Tratarea erorilor

Sugestii posibile pentru consumatorii API despre eroare și de ce a apărut. De asemenea, ar trebui să furnizeze mesaje de eroare la nivel granular.

# 3) Versiune API

Utilizați litera „v” din adresa URL pentru a indica versiunea API. De exemplu-

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

Parametru suplimentar la sfârșitul adresei URL

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

# 4) Filtrare

Permițând utilizatorului să specifice, selectați datele dorite în loc să le furnizați pe toate.
/ contact / sam? nume, vârstă, desemnare, birou
/ contacts? limit = 25 & offset = 20

# 5) Securitate

Marcaj de timp în fiecare cerere și răspuns API. Utilizarea access_token pentru a vă asigura că API-ul este invocat de părțile de încredere.

testarea software-ului relua mostre de 2 ani de experiență

# 6) Analize

Dacă aveți Analytics în API-ul REST vă va oferi o perspectivă bună asupra API-ului testat, mai ales atunci când numărul de înregistrări preluate este foarte mare.

# 7) Documentație

Trebuie furnizată o documentație adecvată, astfel încât consumatorii API să o poată utiliza și să consume serviciile în mod eficient.

# 8) Structura URL

Structura URL-ului ar trebui să rămână simplă și un utilizator ar trebui să poată citi cu ușurință numele domeniului peste el.

De exemplu , https://api.testdomain.com.

Operațiunile care trebuie efectuate prin intermediul API-ului Rest ar trebui, de asemenea, să fie foarte ușor de înțeles și de realizat.

De exemplu, pentru un client de e-mail:

OBȚINE: read / inbox / messages - Preluează lista tuturor mesajelor din căsuța de e-mail
OBȚINE: read / inbox / messages / 10 - Citeste 10amesaj în căsuța de e-mail
POST: create / inbox / folders - Creați un folder nou în căsuța de e-mail
ȘTERGE: Ștergere / spam / mesaje - Ștergeți toate mesajele din dosarul de spam
A PUNE: foldere / căsuță de intrare / subfolder - Actualizați informațiile referitoare la subfolderul din căsuța de e-mail.

Concluzie

Multe organizații preferă să implementeze REST Web API, deoarece este foarte ușor de implementat, are standarde și reguli mai mici de urmat, ușor de accesat, ușor și ușor de înțeles. POSTMAN are avantajele sale atunci când este utilizat cu API-ul RESTful datorită interfeței sale de utilizare ușor de utilizat, ușurinței de utilizare și testare, rata de răspuns mai rapidă și noua caracteristică RUNNER.

În următorul tutorial din această serie Tutorial Rest API, vom automatiza cazurile de testare pe care le-am executat manual.

Lectură recomandată

^