Tutorial Rest API: Arquitectura i restriccions de l'API REST

rest api tutorial rest api architecture

En aquest tutorial, coneixerem l'API REST, els serveis web, l'arquitectura de l'API REST, les restriccions de l'API REST i com provar una API mitjançant POSTMAN:

Prerequisits: Coneixements bàsics de serveis web.

Comprovar aquí per obtenir una comprensió clara dels serveis web.

Què aprendreu:

• Què és l'API REST?
  • Diferència entre SOAP i REST
  • Per què triar REST sobre SOAP?
    • Per què Carter?
  • Arquitectura API REST
  • Restriccions de l'API REST
  • Què és POSTMAN?
  • Com provar API amb Postman?
    • Instal·lació
• Conclusió
  • Lectura recomanada

Què és l'API REST?

L’API és simplement una interfície que els components del programari utilitzen per comunicar-se entre ells. Un servei és una funció ben definida, autònoma i que no depèn de cap altre servei.

Un servei web és un tipus d’API, gairebé totes operen mitjançant HTTP. Quan una API web es desenvolupa mitjançant REST Architecture, s’anomena REST Web API.

A hores d’ara, hi ha dos tipus de serveis web,

• SABÓ
• DESCANS

Diferència entre SOAP i REST

Per què triar REST sobre SOAP?

A continuació, s’expliquen els motius per optar per REST mitjançant SOAP.

• És molt bo per desenvolupar i provar API web.
• REST requereix menys amplada de banda.
• Podem utilitzar AJAX per a les API web basades en REST.
• Requereix una anàlisi general inferior.
• La mida de la càrrega útil creada per JSON és menor.

Hi ha molts clients / eines disponibles al web, cosa que ens permet consumir serveis web RESTful.

Ells són:

• Carter
• Client de descans avançat
• Client DHC Rest
• Sol·licitant
• Insomni
• Assertible
• Cartell

Per què Carter?

• Mostra totes les opcions disponibles.
• Postman té una funció addicional (coneguda com Runner).
• Interfície d'usuari fàcil d'utilitzar i fàcil d'utilitzar.
• Membres o grups comunitaris més grans.

Arquitectura API REST

Es tracta principalment de l'arquitectura del web en un estil arquitectònic de programari. És per a sistemes hipermèdia distribuïts. Una API RESTful aprofita directament les metodologies HTTP definides pel protocol RFC 2616.

Poques definicions

INCENDI significa Interfície de programació d'aplicacions. És un conjunt de definicions, protocols i eines de subrutines per construir el programari de l’aplicació.

Serveis web són alguns codis de programa que contenen dades / mètodes incorporats. L'organització els desplega a través d'Internet per comunicar-se amb usuaris, aplicacions de tercers, etc. Per comunicar els missatges, la majoria d'XML s'utilitza com a sistema de missatgeria. XML simplement codifica totes les comunicacions entre usuaris i aplicacions.

HTTP significa protocol de transferència d’hipertext, utilitzat per la World Wide Web. Defineix com es formaten i es transmeten els missatges i quines accions fan els servidors i navegadors web en resposta a diverses ordres.

Estil arquitectònic, es caracteritzen per les característiques que s’utilitzen per crear una estructura i fins i tot fer-la única. Els estils són de dos tipus: interfície en capes i uniforme.

ODI : També conegut com a identificador de recursos uniforme. Identifica un recurs (document de text, fitxer d'imatge, etc.).
URL: També conegut com a Uniform Resource Locator. És un subconjunt dels URI, que inclou una ubicació de xarxa.
URN : També es coneix com a nom de recurs uniforme és un subconjunt d'URI, que inclouen un nom dins d'un espai determinat, però sense ubicació.

Per exemple,

http://elearning.com/amazon/restapi.html#books

Aquí, a l'exemple anterior

ODI : http://elearning.com/amazon/restapi.html#posts
URL : http://elearning.com/amazon/restapi.html
URN : elearning.com/amazon/restapi.html#posts

com inicialitzar la llista a Java

Per tant, un URL és un URI que identifica un recurs i que també proporciona els mitjans per localitzar el recurs descrivint la manera d’accedir-hi.

Per tant, cada URL pot ser un URI, però el contrari no és cert.

Un servei RESTful s’exposa mitjançant un localitzador de recursos uniforme (URL). Es tracta d’un nom lògic que separa la identitat del recurs del que s’accepta o es retorna.

Una mostra REST Architecture:

Restriccions de l'API REST

Es diu que una interfície API és RESTful si compleix les restriccions següents:

• Interfície uniforme: Significa que, independentment de qualsevol client que estem utilitzant, el concepte bàsic d’implementar i utilitzar els serveis REST seguirà sent el mateix. Totes les API REST desenvolupades haurien de tenir un enfocament comú per al desenvolupament.
• Apàtrides: Això significa que no es desarà cap sessió. Per tant, el servidor no emmagatzemarà cap sol·licitud HTTP enviada per un client. Per tant, per a un servidor, cada sol·licitud HTTP és una sol·licitud nova. Tant se val, quantes vegades es fa la sol·licitud o si el client és l’únic o no.
• Emmagatzemable en memòria cau: La memòria cau significa la freqüència amb què s’accedeix a les dades i respostes des d’una memòria cau en lloc del servidor. El concepte de memòria cau és aplicable mentre s’envia la sol·licitud del client. Per tant, la millora del rendiment es fa des del costat del client.
• Servidor client: El servidor i els clients són independents els uns dels altres quant a la implementació. Un client només ha d’enviar l’URI de la sol·licitud juntament amb o sense autenticació. A continuació, el servidor fa la resta del pas, és a dir, una resposta.
• Sistema de capes: El client només pot enviar la sol·licitud al servidor com a URI de recurs. Però, abans d’enviar la sol·licitud al servidor, existeix l’API REST, que ens proporciona l’arquitectura del sistema en capes. Això vol dir que podem tenir l'API desplegada en un servidor, les dades es desplegen en un altre servidor i l'autenticació en un altre servidor.
• Codi a la carta (opcional): De vegades, un client pot necessitar alguna cosa més que la resposta. L’API REST ens permet enviar un codi executable com a resposta (aquest codi executable pot ser un widget o qualsevol control). Tot i això, és completament opcional si hem activat / implementat aquesta funció.

Poques terminologies més relacionades amb l'API Rest:

Punt final : És la referència a un URL que accepta sol·licituds web. Es pot direccionar un servei web mitjançant la referència del punt final.
Per exemple, Http: // {Domain_URL} //librarygr/libraries.xml

Recursos : És un subconjunt del punt final. Normalment els punts finals exposen alguns objectes que es poden consumir a través dels serveis web. Els recursos són específicament la porció d’un objecte sobre l’URI del punt final.
Per exemple, Http: // {Domain_URL} // api / pg_library / ornithology / swan

Càrrega útil : La càrrega útil és la informació que s’envia mentre es realitza l’operació POST o PUT. Aquesta és la informació especificada al cos de la sol·licitud HTTP.

Les càrregues útils s’envien en format JSON, Per exemple,

Paràmetres :

Podem passar paràmetres de dues maneres.

Paràmetres de consulta : Útil per accedir a parells de claus / valors a la cadena de consulta de l'URL (la part posterior a?)

Millor exemple

http://jsonplaceholder.typicode.com/posts/?id=3

Paràmetres del camí: És útil fer coincidir una part de l'URL com a paràmetre. Podem enviar informació com a paràmetre de camí de la manera següent: Form-data, x-www-form-urlencoded, raw, binari.

quin tipus de prova s'utilitza per verificar que tots els programes d'una aplicació funcionen correctament

Millor exemple:

https://api.github.com/gists/49b05378bb8920d5b4ec54efc27103e2/comments

Què és POSTMAN?

POSTMAN és un client REST, simplement una aplicació que ve amb el navegador Chrome. S'està desenvolupant, tenint en compte els desenvolupadors per facilitar la prova de trucades de l'API. Té la seva pròpia GUI per enviar les sol·licituds de l'API i llegir les respostes de l'API.

Podem realitzar les proves de l'API REST tant manualment com mitjançant automatització.

A la secció següent, aprendrem com provar l'API web manualment mitjançant el client POSTMAN.

Com provar API amb Postman?

Instal·lació

Hem d’accedir al Chrome Web Store . Al navegador Chrome, cerqueu Postman. Feu clic a aquí per afegir-lo al botó Chrome.

Un cop s'hagi instal·lat correctament, podem trobar POSTMAN a l'aplicació Chrome. Simplement feu clic a la icona Postman per obrir POSTMAN. Es trigarà el temps a llançar-se per primera vegada.

Consulteu l’URL següent per entendre com s’utilitza POSTMAN com a eina.

Requisits previs: Es necessita connexió a Internet per accedir als serveis desplegats a través del web. En cas d’accedir als serveis desplegats localment, assegureu-vos que hi hagi prou drets. Es donen privilegis a l’usuari que executa la prova sobre POSTMAN.

URI de recursos ficticis: En aquest tutorial, farem servir un URI fictici en lloc d’un URI real. Ens donarà les respostes que vulgueu, però no es poden fer canvis al servidor.

http://jsonplaceholder.typicode.com

Passos de navegació :

# 1) Un cop llançada l'aplicació POSTMAN, podem veure la pàgina de sol·licitud per defecte.

# 2) Podem veure la llista de trucades API fent clic al menú desplegable. Seleccionant qualsevol de les opcions del menú desplegable, podem sol·licitar la trucada API al servidor.

# 3) Feu clic al botó de la variable Entorn a l'extrem superior dret d'un POSTMAN. Definiu l'entorn específic, on farem la prova. El podem guardar per a una futura execució.

# 4) Es pot accedir a l'entorn desat des del menú desplegable Entorn.

# 5) A continuació, hem d’establir l’URI de recursos al quadre indicat.

# 6) Feu clic al botó Params al costat del camp URI de recursos per especificar paràmetres de consulta

# 7) Feu clic a la pestanya Autorització, seleccioneu el tipus d'autorització al menú desplegable i configureu qualsevol autorització desitjada o simplement deixeu-la com a Sense autorització.

# 8) Feu clic a la pestanya Capçaleres i configureu les capçaleres necessàries, com ara el tipus de contingut

# 9) Feu clic a la pestanya Cos, seleccioneu el botó d'opció Dades del formulari. Especifiqueu els paràmetres necessaris del cos que cal enviar junt amb l'URL de sol·licitud

# 10) Feu clic a la pestanya Cos, seleccioneu el botó d'opció x-www-form-urlencoded. Especifiqueu els paràmetres necessaris del cos que s'han d'enviar com a codificats, juntament amb l'URL de sol·licitud

quin procés requereix versions i proves automatitzades per verificar el programari durant el desenvolupament

# 11) Feu clic a la pestanya Cos, seleccioneu el botó d'opció 'cru'. Especifiqueu els paràmetres necessaris del cos que cal enviar junt amb l'URL de sol·licitud. Es tracta del format JSON real

# 12) Feu clic a la pestanya Cos, seleccioneu el botó d'opció 'binari'. Especifiqueu els paràmetres necessaris del cos (normalment com a fitxer) que cal enviar junt amb l'URL de sol·licitud.

# 13) Un cop hàgim configurat tots els detalls tal com s’especifica més amunt, ara podem “enviar” la sol·licitud. A més, podem desar la sol·licitud d’enviament com a request.json (podem canviar el nom de la sol·licitud).

# 14) Podem veure la llista de sol·licituds realitzades al tauler esquerre de la pestanya Historial.

# 15) A més, podem desar totes les dades relacionades amb la sol·licitud (URI, autorització, paràmetres, cos, etc.) en una col·lecció existent o en una nova col·lecció. Un cop afegida la sol·licitud a la col·lecció, la podem exportar (compartir) i fins i tot podem importar qualsevol col·lecció existent.

Podem compartir la col·lecció com a enllaç o com a biblioteca d’equip mitjançant un simple codi generat. Sempre podem executar tota la col·lecció.

Fins i tot podem publicar la URL de la col·lecció al web perquè tothom que accedeixi a la URL publicada pugui accedir a la col·lecció i consumir els serveis proporcionats per l'API web.

Hi ha una funció per iniciar la sessió a POSTMAN, que ens permet emmagatzemar l’historial, les col·leccions, les dades ambientals i l’emmagatzematge local perquè puguem desar-los i accedir-hi a qualsevol lloc, en qualsevol moment després d’haver iniciat la sessió a POSTMAN.

Corredor

S'utilitza per executar els recursos presents a la carpeta Col·leccions.

Conclusió

La majoria de les empreses adopten l’estil arquitectònic REST per al desenvolupament / implementació de serveis web, ja que es tracta d’una interfície senzilla i fàcil d’utilitzar, que requereix menys formació per als membres existents / nous del projecte. Les organitzacions consideren REST juntament amb els seus serveis web existents.

Llegiu també = >> Tutorial de l'API Flask

Al següent tutorial d'aquesta sèrie d'API REST, analitzarem diferents tipus de codis de resposta, tipus de sol·licituds REST, etc.

Lectura recomanada

• Codis de resposta de l'API Rest i tipus de sol·licituds de descans
• Tutorial POSTMAN: proves d'API mitjançant POSTMAN
• Proves de l'API REST amb cogombre mitjançant l'aproximació BDD
• 10 millors eines de proves d'API el 2021 (eines de proves d'API SOAP i REST)
• Proves d'API REST amb Spring RestTemplate i TestNG
• Com automatitzar les sol·licituds d'API mitjançant Rest Assured i Jenkins
• Com es crea un projecte REST a SoapUI Pro: tutorial núm. 13
• Parasoft SOAtest Tutorial: Eina de prova d'API sense script