rest api tutorial rest api architecture
În acest tutorial, vom afla despre REST API, servicii web, arhitectura REST API, constrângeri REST API și cum se testează un API folosind POSTMAN:
Precondiții: Cunoașterea de bază a serviciilor web.
Verifica Aici pentru a obține o înțelegere clară a serviciilor web.
Ce veți învăța:
Ce este API-ul REST?
API este pur și simplu o interfață, care este utilizată de componentele software pentru a comunica între ele. Un serviciu este o funcție bine definită, autonomă și care nu depinde de alte servicii.
Un serviciu Web este un tip de API, aproape toate operează prin HTTP. Atunci când un API Web este dezvoltat folosind REST Architecture, atunci acesta se numește REST Web API.
De acum, există două tipuri de servicii Web,
- SĂPUN
- ODIHNĂ
Diferența dintre săpun și odihnă
SĂPUN | ODIHNĂ |
---|---|
Putem folosi doar formatul XML pentru a trimite datele în corpul cererii | Putem avea format XML, JSON etc. pentru trimiterea cererii. |
Este un protocol | Este un stil de arhitectură și independent de orice protocol, REST poate utiliza serviciile web SOAP |
Reprezintă Protocolul de acces la obiecte simple | Reprezintă Transferul de stat reprezentativ |
Folosește interfețe de servicii pentru a expune logica de afaceri. | Folosește URI pentru a expune logica de afaceri. |
SOAP are un standard strict de urmat. | Nu există un astfel de standard strict menționat, care să fie urmat de REST. Cu toate acestea, utilizatorul poate respecta câteva standarde în timp ce dezvoltă serviciul web utilizând REST. |
Necesită mai multă lățime de bandă. | Este ușor. |
Își poate defini propria securitate. | REST moștenește măsurile de securitate din transport. |
Cel mai bun exemplu este Google, AMAZON | Cel mai bun exemplu este YAHOO, LINKEDIN, AMAZON |
SOAP folosește protocolul HTTP, SMTP etc. | REST se bazează doar pe HTTP. |
Regulile pentru legarea mesajului, operațiunilor etc. sunt scrise în WSDL | REST urmează formatul WADL pentru descrierea funcționalității oferite de serviciile web |
Este standardizat. | Serviciile REST nu sunt standardizate. |
Necesită mai mult timp de învățare datorită regulilor sale existente, obligatorii etc. | Necesită mai puțin timp pentru a învăța datorită simplității sale. |
De ce să alegeți REST over SOAP?
Punctele de mai jos explică motivele pentru care optați pentru REST peste SOAP.
- Este foarte bun pentru dezvoltarea și testarea API-urilor web.
- REST necesită o lățime de bandă mai mică.
- Putem folosi AJAX pentru API-urile web bazate pe REST.
- Este nevoie de o analiză mai redusă.
- Dimensiunea încărcăturii utile creată de JSON are o dimensiune mai mică.
Există mulți clienți / instrumente disponibile pe web, ceea ce ne permite să consumăm servicii web RESTful.
Sunt:
- Poştaş
- Client de odihnă avansată
- Client DHC Rest
- Solicitant
- Insomnie
- Asertibil
- Poster
De ce poștaș?
- Afișează toate opțiunile disponibile.
- Postman are o caracteristică suplimentară (cunoscută sub numele de Runner).
- UI ușor de utilizat și ușor de utilizat.
- Grup comunitar mai mare / membri.
Arhitectura API REST
Este în principal arhitectura Web-ului într-un stil arhitectural software. Este pentru sistemele hipermedia distribuite. O API RESTful profită direct de metodologiile HTTP definite de protocolul RFC 2616.
Puține definiții
FOC înseamnă Interfață de programare a aplicațiilor. Este un set de definiții, protocoale și instrumente ale subrutinei pentru construirea software-ului aplicației.
Servicii Web sunt câteva coduri de programe care conțin date / metode încorporate. Acestea sunt desfășurate de organizație pe internet pentru a comunica cu utilizatorii, aplicații terțe etc. Pentru comunicarea mesajelor, în principal XML este utilizat ca sistem de mesagerie. XML codifică pur și simplu toate comunicațiile dintre utilizatori și aplicații.
HTTP înseamnă Protocol de transfer hipertext, utilizat de World Wide Web. Acesta definește modul în care sunt formatate și transmise mesajele și ce acțiuni întreprind servere web și browsere ca răspuns la diferite comenzi.
Stil arhitectural, acestea se caracterizează prin caracteristicile care sunt folosite pentru a crea o structură și chiar a o face unică. Stilurile sunt de două tipuri: interfață stratificată și interfață uniformă.
URI : De asemenea, cunoscut sub numele de identificator de resurse uniform. Identifică o resursă (document text, fișier imagine etc.).
URL: De asemenea, cunoscut sub numele de Uniform Resource Locator. Este un subset al URI-urilor, care include o locație de rețea.
URNĂ : De asemenea, cunoscut sub numele de Uniform Resource Name este un subset de URI-uri, care includ un nume într-un spațiu dat, dar fără locație.
De exemplu,
http://elearning.com/amazon/restapi.html#books
Aici, în exemplul de mai sus
URI : http://elearning.com/amazon/restapi.html#posts
URL : http://elearning.com/amazon/restapi.html
URNĂ : elearning.com/amazon/restapi.html#posts
cel mai bun software de recuperare a datelor pentru Windows
Prin urmare, un URL este un URI care identifică o resursă și oferă, de asemenea, mijloacele de localizare a resursei prin descrierea modului de accesare a acesteia.
Deci, fiecare adresă URL poate fi un URI, dar inversul nu este adevărat.
Un serviciu RESTful este expus printr-un Uniform Resource Locator (URL). Acesta este un nume logic care separă identitatea resursei de ceea ce este acceptat sau returnat.
Un eșantion de arhitectură REST:
Constrângeri API REST
Se spune că o interfață API este RESTful dacă îndeplinește următoarele constrângeri:
- Interfață uniformă: Înseamnă că, indiferent de orice client pe care îl folosim, conceptul de bază al implementării și utilizării serviciilor REST va rămâne același. Toate API-urile REST dezvoltate ar trebui să aibă o abordare comună a dezvoltării.
- Fara stare: Aceasta înseamnă că nu trebuie stocată nicio sesiune. Deci, serverul nu va stoca nicio cerere HTTP trimisă de un client. Prin urmare, pentru un server, fiecare cerere HTTP este o cerere nouă. Nu contează, de câte ori este făcută solicitarea sau dacă clientul este unic sau nu.
- În cache: Memorarea în cache înseamnă cât de frecvente sunt accesate date și răspunsuri dintr-un cache în loc de server. Conceptul de cache este aplicabil la trimiterea cererii clientului. Deci, îmbunătățirea performanței se face din partea clientului.
- Client server: Serverul și clienții sunt independenți unul de celălalt în ceea ce privește implementarea. Un client trebuie doar să trimită cererea URI împreună cu sau fără autentificare. Apoi serverul face restul pasului, acesta este un răspuns.
- Sistem stratificat: Clientul poate trimite numai cererea către server ca resursă URI. Dar apoi, înainte ca solicitarea să fie trimisă către server, există REST API, care ne oferă arhitectura sistemului stratificat. Asta înseamnă că putem avea API implementat pe un server, datele sunt implementate pe alt server și autentificare pe alt server.
- Cod la cerere (opțional): Uneori, un client poate avea nevoie de mai mult decât de răspuns. REST API ne permite să trimitem un cod executabil ca răspuns (acest cod executabil poate fi un widget sau orice control). Cu toate acestea, este complet opțional dacă am activat / implementat această caracteristică.
Mai puține terminologii legate de Rest API:
Punct final : Este referința la o adresă URL care acceptă solicitările web. Un serviciu web este adresabil folosind referința punctului final.
De exemplu, Http: // {Domain_URL} //librarygr/libraries.xml
Resurse : Este un subset al punctului final. În mod normal, Endpoints expun unele obiecte care pot fi consumate prin intermediul serviciilor web. Resursele sunt în mod specific acea porțiune a unui obiect peste URI-ul Endpoint.
De exemplu, Http: // {Domain_URL} // api / pg_library / ornithology / swan
Încărcătură utilă : Sarcina utilă este informația care este trimisă în timpul efectuării operației POST sau PUT. Acestea sunt informațiile specificate în corpul cererii HTTP.
Sarcinile utile sunt trimise în format JSON, De exemplu,
{ Id: 1, name:'sam', phones:({title:'mobile',number:9898989899}, {title:'home',number:8888888888}) }
Parametrii :
Putem trece parametrii în două moduri.
Parametrii interogării : Util pentru a accesa perechile cheie / valoare în șirul de interogare al adresei URL (partea de după?)
Cel mai bun exemplu
http://jsonplaceholder.typicode.com/posts/?id=3
întrebări de adresat unui analist de afaceri
Parametrii căii: Este util să se potrivească o parte a adresei URL ca parametru. Putem trimite informații ca parametru de cale în felul următor: Form-data, x-www-form-urlencoded, raw, binar.
Cel mai bun exemplu:
https://api.github.com/gists/49b05378bb8920d5b4ec54efc27103e2/comments
Ce este POSTMAN?
POSTMAN este un client REST, pur și simplu o aplicație care vine cu browserul Chrome. Acesta este în curs de dezvoltare, ținând cont de dezvoltatori pentru a facilita testarea apelurilor API. Are propriul GUI pentru trimiterea cererilor API și citirea răspunsurilor API.
Putem efectua testarea API REST atât manual, cât și prin automatizare.
În secțiunea următoare, vom învăța cum să testăm manual API-ul Web utilizând clientul POSTMAN.
Cum se testează API cu Postman?
Instalare
Trebuie să accesăm Magazin web Chrome . În browserul Chrome, căutați Postman. Clic Aici pentru a-l adăuga la butonul Chrome.
Odată ce este instalat cu succes, putem găsi POSTMAN în aplicația Chrome. Doar faceți clic pe pictograma Postman pentru a deschide POSTMAN. Va dura mult timp pentru lansare pentru prima dată.
Vă rugăm să consultați următoarea adresă URL pentru a înțelege modul de utilizare POŞTAŞ ca instrument.
Cerințe prealabile: Conexiunea la internet este necesară pentru a accesa serviciile desfășurate pe web. În cazul accesării serviciilor desfășurate local, asigurați-vă că există suficiente drepturi, privilegii sunt acordate utilizatorului care execută testul peste POSTMAN.
URI pentru resurse fictive: În acest tutorial, vom folosi un URI fals în locul unui URI real. Acesta ne va oferi răspunsurile dorite, dar nu se pot face modificări la server.
http://jsonplaceholder.typicode.com
Pași de navigare :
# 1) Odată ce aplicația POSTMAN este lansată, putem vedea pagina Solicitare în mod implicit.
#Două) Putem vedea lista apelurilor API făcând clic pe meniul derulant. Selectând oricare dintre opțiuni din meniul derulant, putem solicita apelul API către server.
# 3) Faceți clic pe butonul variabilă de mediu din colțul din dreapta sus al unui POSTMAN. Setați mediul specific, unde vom testa. Îl putem salva pentru execuția viitoare.
# 4) Mediul salvat poate fi accesibil din meniul derulant Mediu.
# 5) Apoi, trebuie să setăm Resurse URI în caseta dată.
# 6) Faceți clic pe butonul Params de lângă câmpul Resurse URI pentru a specifica parametrii de interogare
# 7) Faceți clic pe fila Autorizare, selectați tipul de autorizare din meniul derulant și setați orice autorizație dorită sau, pur și simplu, o puteți lăsa fără autorizație.
# 8) Faceți clic pe fila Anteturi și setați anteturile necesare, cum ar fi tipul de conținut
# 9) Faceți clic pe fila Corp, selectați butonul radio formular-date. Specificați parametrii corpului necesari care trebuie să fie trimiși împreună cu adresa URL a solicitării
aplicație de unde puteți descărca videoclipuri YouTube
# 10) Faceți clic pe fila Corp, selectați butonul radio x-www-form-urlencoded. Specificați parametrii corpului necesari care trebuie să fie expediați ca codificați, împreună cu adresa URL a solicitării
#unsprezece) Faceți clic pe fila Corp, selectați butonul radio „brut”. Specificați parametrii corpului necesari care trebuie să fie trimiși împreună cu adresa URL a solicitării. Acesta este în format JSON real
# 12) Faceți clic pe fila Corp, selectați butonul radio „binar”. Specificați parametrii de corp necesari (în mod normal ca fișier) care trebuie să fie trimiși împreună cu adresa URL a cererii.
# 13) Odată ce am configurat toate detaliile specificate mai sus, acum putem „trimite” solicitarea. De asemenea, putem salva cererea de trimitere ca request.json (putem schimba numele cererii).
# 14) Putem vedea lista Cererilor făcute, în panoul din partea stângă sub fila Istoric.
#cincisprezece) De asemenea, putem salva toate detaliile legate de cerere (URI, autorizare, parametri, corp etc.) sub o colecție existentă sau o nouă colecție. Odată ce cererea este adăugată la colecție, o putem exporta (partaja) și chiar putem importa orice colecție existentă.
Putem partaja colecția ca un link sau ca o bibliotecă de echipă printr-un cod generat simplu. Putem rula întotdeauna întreaga suită de colecție.
Chiar și noi putem publica adresa URL a colecției pe web, astfel încât oricine accesează adresa URL publicată să poată accesa colecția și să consume serviciile furnizate de API-ul Web.
Există o funcție de conectare la POSTMAN, care ne permite să stocăm istoria, colecțiile, datele de mediu, stocarea locală, astfel încât să o putem salva și să o putem accesa oriunde, oricând după ce ne-am conectat la POSTMAN.
Alergător
Este folosit pentru a rula resursele prezente în folderul Colecții.
Concluzie
Majoritatea companiilor adoptă stilul arhitectural REST pentru dezvoltarea / implementarea serviciilor web, deoarece este o interfață simplă și ușor de utilizat, care necesită mai puțină instruire pentru membrii existenți / noi ai proiectului. Organizațiile iau în considerare REST împreună cu serviciile lor web existente.
Citiți și = >> Tutorial API Flask
În următorul tutorial din această serie REST API, vom discuta diferite tipuri de coduri de răspuns, tipuri de cereri REST etc.
Lectură recomandată
- Coduri de răspuns API Rest și tipuri de cereri de repaus
- Tutorial POSTMAN: Testarea API folosind POSTMAN
- Testarea API REST cu castraveți folosind abordarea BDD
- Cele mai bune 10 instrumente de testare API în 2021 (SOAP și REST API Testing Tools)
- Testarea API REST cu Spring RestTemplate și TestNG
- Cum să automatizați cererile API folosind Rest Assured și Jenkins
- Cum să creați un proiect REST în SoapUI Pro: Tutorial nr. 13
- Parasoft SOAtest Tutorial: Instrument de testare API fără script