Tutorial de la API de Rest: Restricciones y arquitectura de la API de REST

rest api tutorial rest api architecture

En este tutorial, aprenderemos sobre API REST, servicios web, arquitectura de API REST, restricciones de API REST y cómo probar una API usando POSTMAN:

Prerrequisitos: Conocimientos básicos de Servicios Web.

Controlar Aquí para obtener una comprensión clara de los servicios web.

Lo que vas a aprender:

• ¿Qué es la API REST?
  • Diferencia entre SOAP y REST
  • ¿Por qué elegir REST sobre SOAP?
    • ¿Por qué Postman?
  • Arquitectura de API REST
  • Restricciones de la API REST
  • ¿Qué es el CARTERO?
  • ¿Cómo probar API con Postman?
    • Instalación
• Conclusión
  • Lectura recomendada

¿Qué es la API REST?

La API es simplemente una interfaz que utilizan los componentes de software para comunicarse entre sí. Un servicio es una función bien definida, autónoma y que no depende de ningún otro servicio.

Un servicio web es un tipo de API, casi todas operan a través de HTTP. Cuando se desarrolla una API web utilizando la arquitectura REST, se denomina API web REST.

A partir de ahora, existen dos tipos de servicios web,

• JABÓN
• DESCANSO

Diferencia entre SOAP y REST

¿Por qué elegir REST sobre SOAP?

Los siguientes puntos explican las razones para optar por REST en lugar de SOAP.

• Es muy bueno para desarrollar y probar API web.
• REST requiere menos ancho de banda.
• Podemos usar AJAX para las API web basadas en REST.
• Requiere una sobrecarga de análisis menor.
• El tamaño de la carga útil creado por JSON es menor.

Hay muchos clientes / herramientas disponibles en la web, lo que nos permite consumir servicios web RESTful.

Son:

• Cartero
• Cliente de descanso avanzado
• Cliente DHC Rest
• Solicitante
• Insomnio
• Asertible
• Póster

¿Por qué Postman?

• Muestra todas las opciones disponibles.
• Postman tiene una función adicional (conocida como Runner).
• Interfaz de usuario amigable y fácil de usar.
• Grupos / miembros comunitarios más grandes.

Arquitectura de API REST

Es principalmente la arquitectura de la Web en un estilo de arquitectura de software. Es para sistemas hipermedia distribuidos. Una API RESTful aprovecha directamente las metodologías HTTP definidas por el protocolo RFC 2616.

Pocas definiciones

FUEGO significa interfaz de programación de aplicaciones. Es un conjunto de definiciones de subrutinas, protocolos y herramientas para construir el software de la aplicación.

Servicios web son algunos códigos de programa que contienen datos / métodos incorporados. Estos son desplegados por la organización a través de Internet para comunicarse con usuarios, aplicaciones de terceros, etc. Para comunicar los mensajes, principalmente se utiliza XML como sistema de mensajería. XML simplemente codifica todas las comunicaciones entre usuarios y aplicaciones.

HTTP significa Protocolo de transferencia de hipertexto, utilizado por la World Wide Web. Define cómo se formatean y transmiten los mensajes, y qué acciones toman los servidores web y los navegadores en respuesta a varios comandos.

Estilo arquitectónico, estos se caracterizan por las características que se utilizan para crear una estructura e incluso hacerla única. Los estilos son de dos tipos: interfaz en capas y uniforme.

ODIO : También conocido como identificador uniforme de recursos. Identifica un recurso (documento de texto, archivo de imagen, etc.).
URL: También conocido como localizador uniforme de recursos. Es un subconjunto de los URI que incluye una ubicación de red.
URNA : También conocido como Uniform Resource Name es un subconjunto de URI, que incluye un nombre dentro de un espacio determinado, pero sin ubicación.

Por ejemplo,

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

Aquí, en el ejemplo anterior

ODIO : http://elearning.com/amazon/restapi.html#posts
URL : http://elearning.com/amazon/restapi.html
URNA : elearning.com/amazon/restapi.html#posts

el mejor software de creación de juegos para principiantes

Por lo tanto, una URL es un URI que identifica un recurso y también proporciona los medios para localizar el recurso describiendo la forma de acceder a él.

Entonces, cada URL puede ser un URI, pero lo contrario no es cierto.

Un servicio RESTful se expone a través de un localizador uniforme de recursos (URL). Este es un nombre lógico que separa la identidad del recurso de lo que se acepta o devuelve.

Una muestra de arquitectura REST:

Restricciones de la API REST

Se dice que una interfaz API es RESTful si cumple las siguientes restricciones:

• Interfaz uniforme: Significa que, independientemente del cliente que estemos utilizando, el concepto básico de implementación y uso de los servicios REST seguirá siendo el mismo. Todas las API REST desarrolladas deben tener un enfoque común de desarrollo.
• Apátrida: Esto significa que no se almacenará ninguna sesión. Por lo tanto, el servidor no almacenará ninguna solicitud HTTP enviada por un cliente. Por lo tanto, para un servidor, todas y cada una de las solicitudes HTTP son una nueva solicitud. No importa cuántas veces se haga la solicitud o el cliente sea el único o no.
• En caché: El almacenamiento en caché significa la frecuencia con la que se accede a los datos y las respuestas desde un caché en lugar del servidor. El concepto de almacenamiento en caché es aplicable al enviar la solicitud del cliente. Entonces, la mejora del rendimiento se realiza en el lado del cliente.
• Servidor de cliente: El servidor y los clientes son independientes entre sí en términos de implementación. Un cliente solo necesita enviar el URI de solicitud junto con o sin autenticación. Luego, el servidor toma el resto del paso, es una respuesta.
• Sistema en capas: El cliente puede enviar solo la solicitud al servidor como URI de recurso. Pero luego, antes de que la solicitud se envíe al servidor, existe una API REST, que nos proporciona la arquitectura del sistema en capas. Eso significa que podemos implementar la API en un servidor, los datos se implementan en otro servidor y la autenticación en otro servidor.
• Código a pedido (opcional): A veces, un cliente puede necesitar algo más que la respuesta. La API REST nos permite enviar un código ejecutable como respuesta (este código ejecutable puede ser un widget o cualquier control). Sin embargo, es completamente opcional si hemos habilitado / implementado esta función.

Algunas terminologías más relacionadas con Rest API:

Punto final : Es la referencia a una URL que acepta solicitudes web. Un servicio web es direccionable mediante la referencia de punto final.
Por ejemplo, Http: // {Domain_URL} //librarygr/libraries.xml

Recursos : Es un subconjunto del punto final. Normalmente, los puntos finales exponen algunos objetos que se pueden consumir a través de servicios web. Los recursos son específicamente la parte de un objeto sobre el URI del punto final.
Por ejemplo, Http: // {Domain_URL} // api / pg_library / ornithology / swan

Carga útil : Payload es la información que se envía mientras se realiza la operación POST o PUT. Ésta es la información especificada en el cuerpo de la solicitud HTTP.

Las cargas útiles se envían en formato JSON, Por ejemplo,

Parámetros :

Podemos pasar parámetros de dos formas.

Parámetros de consulta : Útil para acceder a pares clave / valor en la cadena de consulta de la URL (la parte después de?)

Mejor ejemplo

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

Parámetros de ruta: Es útil hacer coincidir una parte de la URL como parámetro. Podemos enviar información como un parámetro de ruta de la siguiente manera: Form-data, x-www-form-urlencoded, raw, binary.

Mejor ejemplo:

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

¿Qué es el CARTERO?

POSTMAN es un cliente REST, simplemente una aplicación que viene con el navegador Chrome. Se está desarrollando teniendo en cuenta a los desarrolladores para facilitar las pruebas de llamadas a la API. Tiene su propia GUI para enviar solicitudes de API y leer respuestas de API.

Podemos realizar las pruebas de API REST tanto de forma manual como automática.

En la siguiente sección, aprenderemos cómo probar Web API manualmente usando el cliente POSTMAN.

¿Cómo probar API con Postman?

Instalación

Necesitamos acceder al Tienda virtual de Chrome . En el navegador Chrome, busque Postman. Hacer clic Aquí para agregarlo al botón de Chrome.

Una vez que se haya instalado correctamente, podemos encontrar POSTMAN en la aplicación Chrome. Simplemente haga clic en el icono del cartero para abrir CARTERO. Llevará tiempo lanzarse por primera vez.

Consulte la siguiente URL para comprender cómo utilizar CARTERO como una herramienta.

Prerrequisitos: Se requiere conexión a Internet para acceder a los servicios implementados en la web. En caso de acceder a los servicios implementados localmente, asegúrese de que se otorguen suficientes derechos, privilegios al usuario que está ejecutando la prueba sobre POSTMAN.

URI de recurso ficticio: En este tutorial, usaremos un URI ficticio en lugar de un URI real. Nos dará las respuestas deseadas, pero no se pueden realizar cambios en el servidor.

http://jsonplaceholder.typicode.com

Pasos de navegación :

#1) Una vez que se lanza la aplicación POSTMAN, podemos ver la página Solicitar por defecto.

#2) Podemos ver la lista de llamadas a la API haciendo clic en el menú desplegable. Al seleccionar cualquiera de las opciones del menú desplegable, podemos solicitar la llamada API al servidor.

#3) Haga clic en el botón Variable de entorno en la esquina superior derecha de un CARTERO. Establecer el entorno específico, donde vamos a probar. Podemos guardarlo para una ejecución futura.

el mejor software para monitorear la temperatura de la CPU y la gpu

#4) Se puede acceder al entorno guardado desde el menú desplegable Entorno.

#5) A continuación, debemos configurar el URI de recurso en el cuadro dado.

#6) Haga clic en el botón Parámetros junto al campo URI de recurso para especificar los parámetros de consulta.

#7) Haga clic en la pestaña Autorización, seleccione el tipo de autorización en el menú desplegable y configure la autorización que desee o, simplemente, déjela como Sin autorización.

#8) Haga clic en la pestaña Encabezados y configure los encabezados requeridos como el tipo de contenido

#9) Haga clic en la pestaña Cuerpo, seleccione el botón de opción de datos de formulario. Especifique los parámetros del cuerpo requeridos que deben enviarse junto con la URL de la solicitud

#10) Haga clic en la pestaña Cuerpo, seleccione el botón de radio x-www-form-urlencoded. Especifique los parámetros del cuerpo necesarios que deben enviarse codificados, junto con la URL de la solicitud

#11) Haga clic en la pestaña Cuerpo, seleccione el botón de opción 'sin procesar'. Especifique los parámetros de cuerpo requeridos que deben enviarse junto con la URL de solicitud. Esto está en formato JSON real

#12) Haga clic en la pestaña Cuerpo, seleccione el botón de opción 'binario'. Especifique los parámetros del cuerpo requeridos (normalmente como un archivo) que deben enviarse junto con la URL de la solicitud.

#13) Una vez que configuramos todos los detalles como se especificó anteriormente, ahora podemos 'Enviar' la solicitud. Además, podemos guardar la solicitud de envío como request.json (podemos cambiar el nombre de la solicitud).

#14) Podemos ver la lista de Solicitudes realizadas, en el panel lateral izquierdo en la pestaña Historial.

#15) Además, podemos guardar todos los detalles relacionados con la Solicitud (URI, Autorización, Parámetros, cuerpo, etc.) bajo una Colección existente o una Colección nueva. Una vez que la Solicitud se agrega a la Colección, podemos exportarla (compartirla) e incluso importar cualquier Colección existente.

Podemos compartir la colección como un enlace o como una biblioteca de equipo mediante un código generado simple. Siempre podemos ejecutar toda la suite Collection.

Incluso podemos publicar la URL de la colección en la web para que cualquiera que acceda a la URL publicada pueda acceder a la colección y consumir los servicios proporcionados por Web API.

Hay una función para iniciar sesión en POSTMAN, que nos permite almacenar el historial, las colecciones, los datos ambientales, el almacenamiento local para que podamos guardarlo y poder acceder a él en cualquier lugar, en cualquier momento después de haber iniciado sesión en POSTMAN.

Corredor

Se utiliza para ejecutar los recursos presentes en la carpeta Colecciones.

Conclusión

La mayoría de las empresas están adoptando el estilo arquitectónico REST para el desarrollo / implementación de servicios web porque es una interfaz simple y fácil de usar, que requiere menos capacitación para los miembros nuevos / existentes del proyecto. Las organizaciones están considerando REST junto con sus servicios web existentes.

tipo de prueba en ingeniería de software

Leer también = >> Tutorial de API de matraces

En el siguiente tutorial de esta serie de API REST, discutiremos diferentes tipos de códigos de respuesta, tipos de solicitudes REST, etc.

Lectura recomendada

• Códigos de respuesta de API de descanso y tipos de solicitudes de descanso
• Tutorial POSTMAN: Pruebas de API con POSTMAN
• Prueba de API REST con pepino utilizando el enfoque BDD
• Las 10 mejores herramientas de prueba de API en 2021 (herramientas de prueba de API SOAP y REST)
• Pruebas de API REST con Spring RestTemplate y TestNG
• Cómo automatizar las solicitudes de API con Rest Assured y Jenkins
• Cómo crear un proyecto REST en SoapUI Pro: Tutorial n. ° 13
• Tutorial de Parasoft SOAtest: Herramienta de prueba de API sin script