¿Qué es la API REST? Una visión general

¿Qué es REST?

El acrónimo REST se define como “Transferencia de estado representacional” y está diseñado para aprovechar los protocolos HTTP existentes cuando se usa para las API web. Es muy flexible porque no está atado a recursos o métodos y tiene la capacidad de manejar diferentes llamadas y formatos de datos. Debido a que la API REST no está restringida a un formato XML como SOAP, puede devolver muchos otros formatos según lo que se necesite. Si un servicio se adhiere a este estilo, se considera una aplicación “RESTful”. REST permite que los componentes accedan y administren funciones dentro de otra aplicación.

REST se definió inicialmente en una disertación de Roy Fielding hace veinte años. Propuso estos estándares como una alternativa a SOAP (El Protocolo simple de acceso a objetos es un estándar simple para acceder a objetos e intercambiar mensajes estructurados dentro de un entorno informático distribuido). REST (o RESTful) define las reglas generales utilizadas para regular las interacciones entre aplicaciones web que utilizan el protocolo HTTP para operaciones CRUD (crear, recuperar, actualizar, eliminar).

¿Qué es una API?

Una API (o interfaz de programación de aplicaciones) proporciona un método de interacción entre dos sistemas.

¿Qué es una API RESTful?

Una API RESTful (o interfaz de programa de aplicación) utiliza solicitudes HTTP para OBTENER, PONER, PUBLICAR y ELIMINAR datos siguiendo los estándares REST. Esto permite que dos piezas de software se comuniquen entre sí. En esencia, la API REST es un conjunto de llamadas remotas que utilizan métodos estándar para devolver datos en un formato específico.

Los sistemas que interactúan de esta manera pueden ser muy diferentes. Cada aplicación puede usar un lenguaje de programación, un sistema operativo, una base de datos, etc. únicos. Entonces, ¿cómo creamos un sistema que pueda comunicarse y comprender fácilmente otras aplicaciones? Aquí es donde se utiliza la API Rest como sistema de interacción.

Al usar una API RESTful, debemos determinar de antemano qué recursos queremos exponer al mundo exterior. Por lo general, el servicio API RESTful se implementa teniendo en cuenta las siguientes ideas:

  • Formato: No debe haber restricciones en el formato de intercambio de datos.
  • Implementación: REST se basa completamente en HTTP
  • Definición del servicio: debido a que REST es muy flexible, la API se puede modificar para garantizar que la aplicación comprenda el formato de solicitud/respuesta.
  • La API RESTful se centra en los recursos y en la eficacia con la que realiza operaciones con ella mediante HTTP.

Las características del estilo de diseño de la API REST indican:

  • Cada entidad debe tener un identificador único.
  • Se deben utilizar métodos estándar para leer y modificar datos.
  • Debe proporcionar soporte para diferentes tipos de recursos.
  • Las interacciones deben ser sin estado.

Para que REST se ajuste a este modelo, debemos cumplir con las siguientes reglas:

  • Arquitectura cliente-servidor: la interfaz está separada del depósito de datos del lado del servidor. Esto permite flexibilidad y el desarrollo de componentes independientemente unos de otros.
  • Separación: las conexiones del cliente no se almacenan en el servidor entre solicitudes.
  • Capacidad de almacenamiento en caché: debe indicarse explícitamente si el cliente puede almacenar respuestas.
  • Multinivel: la API debería funcionar ya sea que interactúe directamente con un servidor o a través de una capa adicional, como un balanceador de carga.

Componentes HTTP

Hay dos componentes principales aquí. La estructura de solicitud HTTP y la estructura de respuesta HTTP.

La estructura de solicitud HTTP tiene los siguientes atributos:

  • Línea de solicitud: define el tipo de mensaje.
  • Campos de encabezado: estos campos definen el cuerpo del mensaje, los parámetros de transmisión y otra información.
  • Cuerpo: el cuerpo de la solicitud, opcional.

La estructura de respuesta HTTP tiene los siguientes atributos:

  • Línea de estado: proporciona un código de estado.
  • Campos de encabezado: muestra el campo de respuesta del encabezado.
  • Cuerpo: un cuerpo de mensaje opcional.

Todas las interacciones con un servidor se reducen a cuatro operaciones básicas:
(Cuatro es el mínimo, pero en otras implementaciones puede haber muchos más).

  1. Recibir datos del servidor (normalmente en formato JSON o XML).
  2. Agregar nuevos datos al servidor.
  3. Modificación de datos esenciales en el servidor.
  4. Eliminar datos en el servidor.

También existe, como se señaló anteriormente, el concepto de operación CRUD. CRUD es un acrónimo utilizado para las cuatro funciones esenciales utilizadas cuando se trabaja con datos:

  • Crear
  • Leer
  • Actualizar
  • Borrar

El concepto CRUD fue introducido en 1983 por James Martin como las clasificaciones estándar de manipulación de datos. Para realizar estas operaciones, se utilizan varios métodos de solicitud HTTP.

  • GET: obtenga información detallada sobre el recurso.
  • POST: la publicación crea un nuevo recurso.
  • PUT: pone actualizaciones de un recurso existente.
  • ELIMINAR: eliminar elimina un recurso existente.

Códigos de estado HTTP

Anteriormente, cuando se realizaba una de estas solicitudes mediante uno de estos métodos, podíamos encontrar errores y no obtener ninguna respuesta. Para resolver este problema, se idearon códigos de estado HTTP.

1xx: Información

  • 100: continuar

2xx: Éxito

  • 200: Bien
  • 201: Creado
  • 202: Aceptado
  • 204: Sin contenido

3xx: redirigir

  • 301 Movido Permanentemente
  • 307: Redirección temporal

4xx: error del cliente

  • 400 Petición Incorrecta
  • 401: no autorizado
  • 403: Prohibido
  • 404 No encontrado

Error del servidor 5xx

  • Error interno de servidor 500
  • 501: No implementado
  • 502 Puerta de enlace no válida
  • 503 Servicio no Disponible
  • 504: tiempo de espera de puerta de enlace

Es posible que ya haya encontrado algunos de estos errores más de una vez, especialmente los errores 404 bastante populares.

OBTENER HTTP

Ahora, veamos un example usando métodos para crear servicios de API Rest.

Usamos HTTP GET para obtener (o leer) una representación de un recurso. Si la dirección se recibe correctamente (sin errores), GET devuelve una representación JSON o XML en combinación con el código de estado HTTP 200 (OK). En caso de error se suele devolver el código 404 (NO ENCONTRADO) o 400 (MAL SOLICITUD).

  • OBTENER https://www.example.com/api/v1.0/usuarios
    (devuelve una lista de usuarios)
  • OBTENER https://www.example.com/api/v1.0/users/ellen
    (devolver información de usuario con id ellen)
  • OBTENER https://www.example.com/api/v1.0/users/12345/pedidos
    (devuelve una lista de pedidos de usuarios con id ellen)

HTTP PUT

HTTP PUT se usa comúnmente para proporcionar la capacidad de actualizar un recurso. Si la solicitud PUT tiene éxito, se devuelve el código 200 (o 204 si no se proporcionó ningún valor para la actualización). Vale la pena señalar que la solicitud PUT no es segura ya que modifica los recursos del lado del servidor. Pero al enviar datos utilizando el método PUT, los datos no desaparecerán, se ubicarán donde estaban antes y la ejecución repetida de la solicitud PUT no cambiará el estado general del sistema.

  • PONER https://www.example.com/api/v1.0/users/ellen
    (actualizar datos de usuario con id ellen)
  • PONER https://www.example.com/api/v1.0/users/ellen/orders/12345
    (actualice los datos del pedido con id 12345 para un usuario con id ellen)

PUBLICACIÓN HTTP

La solicitud HTTP POST se usa más comúnmente para crear nuevos recursos. Tradicionalmente, se utiliza para crear recursos anidados. En otras palabras, al crear un nuevo recurso, se envía una solicitud POST al recurso principal. Por lo tanto, el servicio asume la responsabilidad y establece la conexión del recurso creado con el recurso principal, asigna una ID al nuevo recurso, etc. Tras la creación exitosa, un código HTTP 201 (o posiblemente un código 202 si el sistema está ejecutando tareas en segundo plano). para crear realmente el objeto solicitado) y la dirección del recurso creado también se transmite en el encabezado ‘Ubicación’.

PUBLICAR https://www.example.com/api/v1.0/clientes
(crear un nuevo recurso en la sección de clientes)

PUBLICAR https://www.example.com/api/v1.0/customers/ellen/pedidos
(crear un pedido para un recurso con id ellen)

ELIMINAR HTTP

HTTP DELETE se usa para eliminar recursos con una identificación específica. Tras una eliminación exitosa, se devuelve el estado 200 (OK). También es posible utilizar el estado 204 (SIN CONTENIDO) sin el cuerpo de la respuesta.

  • ELIMINAR https://www.example.com/api/v1.0/clientes/ellen
    (quitar un recurso con id ellen de clientes)
  • ELIMINAR https://www.example.com/api/v1.0/customers/ellen/orders/10 (eliminar un pedido con id 10 de un recurso con id ellen)

Subtipos de API REST

La API Rest tiene los 3 formatos más utilizados para proporcionar recursos. A veces se les llama un subtipo.

  • XML de la API de REST – Este formato es similar al método anterior utilizado por las especificaciones SOAP (Protocolo simple de acceso a objetos).
  • REST API JSON – Este formato se utiliza cuando se emplea un formato de texto para el intercambio de datos basado en JavaScript. Este formato es el más utilizado actualmente.
  • REST API GraphQL – Este formato fue diseñado para abordar la necesidad de mayor flexibilidad y eficiencia. Es el método de especificación más nuevo y popular.

Hay bastantes temas populares sobre cuál es mejor usar y por qué, así como numerosas comparaciones de uso.

Conclusión

En este tutorial, hemos aprendido sobre los conceptos REST, API y RESTful API. Hemos explorado qué es, para qué se usan y cómo se aplican. Los métodos de interacción utilizados en REST API son un concepto bastante amplio y no hay especificaciones exactas. Finalmente, aprendimos que la API REST no es un estándar en sí mismo, sino un estilo arquitectónico utilizado para las interacciones de los componentes. Para un estudio más profundo, recomendamos un examen más profundo de los métodos REST API JSON y REST API GraphQL y aplicarlos en la práctica.

Nuestros equipos de soporte están llenos de talentosos técnicos de Linux y administradores de sistemas que tienen un conocimiento profundo de múltiples tecnologías de alojamiento web, especialmente las que se analizan en este artículo.

Si es un servidor VPS completamente administrado, Cloud Dedicado, privado de VMWare Cloudservidor principal privado o propietario de un servidor dedicado y no se siente cómodo realizando cualquiera de los pasos descritos, puede comunicarse con nosotros por teléfono al 800.580.4985, un chat o ticket de soporte para ayudarlo con este proceso.

Related Posts