Students Save 30%! Learn & create with unlimited courses & creative assets Students Save 30%! Save Now
Advertisement
  1. Code
  2. Node.js
Code

Códifica Su Primera API con Node.js y Express: Comprensión REST API

by
Difficulty:BeginnerLength:MediumLanguages:
This post is part of a series called Code Your First API With Node.js and Express.
Code Your First API With Node.js and Express: Set Up the Server

Spanish (Español) translation by Jean Perez (you can also view the original English article)

Comprensión REST y APIs RESTful

Si usted ha pasado cualquier cantidad de tiempo con el desarrollo web moderno, habrá venido a través de términos como REST y API. Si usted ha oído hablar de estos términos o trabaja con APIs pero no tiene una comprensión completa de cómo funcionan o cómo construir su propia API, esta serie es para ti.

En esta serie de tutoriales, vamos a empezar con un resumen del REST de principios y conceptos. Luego nos dirigimos a crear nuestra propia API completa que se ejecuta en un servidor Node.js Express y se conecta a una base de datos MySQL. Después de terminar esta serie, debe sentirse seguro de construcción de su propio API o adentrarse en la documentación de un API existente.

Requisitos Previos

Para obtener el máximo provecho de este tutorial, ya debe tener unos conocimientos básicos de línea de comandos, conocer los fundamentos de JavaScript y tienen Node.js instalada a nivel mundial.

¿Qué Son API RESTful y REST?

Representational State Transfer, o REST, describe una arquitectura de servicios web. REST se compone de un conjunto de normas o restricciones para intercambio de datos entre diferentes sistemas, y sistemas que implementan el REST son conocidos como RESTful. REST es un concepto abstracto, no un lenguaje, marco o tipo de software.

Una analogía floja para el REST sería mantener una colección de vinilo vs usando un servicio de música streaming. Con la colección de vinilo física, cada registro debe ser duplicada en su totalidad para compartir y distribuir copias. Sin embargo, con un servicio de streaming, se puede compartir la misma música en perpetuidad a través de una referencia a algunos datos, como un título de la canción. En este caso, la música es un servicio RESTful, y la colección de vinilo es un servicio RESTful no.

Una API es una interfaz de programación de aplicaciones, una interfaz que permite que los programas de software para comunicarse con los demás. Una API RESTful es simplemente un API que se adhiere a los principios y las limitaciones del resto. En una API de Web, un servidor recibe una solicitud a través de un punto final de la URL y envía una respuesta a cambio, que es a menudo datos en un formato como JSON.

Principios de REST

Seis rectores restricciones definen la arquitectura de REST, que se detallan a continuación.

  1. Interfaz Uniforme: La interfaz de componentes debe ser el mismo. Esto significa que usando el estándar URI para identificar los recursos, en otras palabras, los caminos que se podrían escribir en la barra de direcciones del navegador.
  2. Cliente-Servidor: Existe una separación de preocupaciones entre el servidor que almacena y manipula los datos, y el cliente, que solicita y muestra la respuesta.
  3. Interacciones Apátridas: Toda la información sobre cada petición está contenida en cada solicitud individual y no depende de estado de sesión.
  4. Caché: El cliente y el servidor pueden almacenar en caché recursos.
  5. Capas de Sistema: El cliente puede conectarse al servidor, o una capa intermedia como un equilibrador de carga.
  6. Código Bajo Demanda (Opcional): un cliente puede descargar el código, que reduce la visibilidad desde el exterior.

Solicitud y Respuesta

Ustedes ya estarán familiarizados con el hecho de que todos los sitios web tienen direcciones URL que comienzan con http (o https para la versión de segura). HyperText Transfer Protocol o HTTP, es el método de comunicación entre clientes y servidores en internet.

Vemos más obviamente en la barra de URL de nuestros navegadores, pero HTTP se puede utilizar para solicitar más que sitios web desde los servidores. Cuando vaya a una dirección URL en la web, realmente haces una petición GET sobre recurso específico, y el sitio web de que ves es el cuerpo de la respuesta. Vamos a ir sobre GET y otros tipos de solicitudes poco.

Obras HTTP mediante la apertura de una conexión TCP (Protocolo de Control de Transmisión) a un puerto de servidor (80 para http, 443 para https) para hacer una petición y el servidor escuchado responde con un estado y un cuerpo.

Debe consistir en una petición de una URL, un método, información de encabezado y un cuerpo.

Métodos de Petición

Hay cuatro principales métodos HTTP, también conocidos como verbos HTTP, que se utilizan comúnmente para interactuar con la web API. Estos métodos definen la acción que se realizará con cualquier recurso dado.

Métodos de la petición HTTP libremente corresponden al paradigma de CRUD, que significa Crear, Actualizar, Leer, Borrar. Aunque CRUD se refiere a las funciones utilizadas en las operaciones de base de datos, podemos aplicar estos principios de diseño a los verbos HTTP en un API RESTful.

Acción Método de Solicitud Definición
Leer GET Recupera un recurso
Crear POST Crea un nuevo recurso
Actualización PUT Actualiza un recurso existente
Eliminar DELETE Borra un recurso

GET es una operación segura, de sólo lectura que no alterará el estado de un servidor. Cada vez que golpeas una URL en su navegador, tales como https://www.google.com, están enviando una petición GET a los servidores de Google.

POST se utiliza para crear un nuevo recurso. Un ejemplo familiar de POST es registrarte como usuario en un sitio web o aplicación. Después de enviar el formulario, una solicitud POST con los datos del usuario puede enviarse al servidor, que luego escribirán esta información en una base de datos.

PUT un recurso existente, que puede utilizarse para editar la configuración de un usuario existente actualiza. A diferencia de los POST, PUT es idempotent, es decir que la misma llamada se puede hacer varias veces sin producir un resultado diferente. Por ejemplo, si usted envía la misma petición POST para crear un nuevo usuario en una base de datos varias veces, crearía un nuevo usuario con los mismos datos para cada solicitud que hiciste. Sin embargo, usando la misma petición de PUT en el mismo usuario continuamente produciría el mismo resultado.

DELETE, como su nombre indica, simplemente borra un recurso existente.

Códigos de Respuesta

Una vez que una solicitud pasa a través del cliente al servidor, el servidor enviará nuevamente una respuesta HTTP, que incluye metadatos acerca de la respuesta conocida como cabeceras, así como el cuerpo. La primera y más importante parte de la respuesta es el estado del código, que indica si una solicitud fue exitosa, si hubo un error, o si debe tomar otra acción.

El más bien conocido código de respuesta de con que ustedes estarán familiarizados es 404, lo que significa No se Encuentra. 404 es parte de la clase 4xx del códigos de estado, que indican errores de cliente. Hay cinco clases de códigos de estado que cada uno contiene una variedad de respuestas.

  • 1xx: Información
  • 2xx: Exito
  • 3xx: Redirección
  • 4xx: Error de Cliente
  • 5xx: Error del Servidor

Otras respuestas comunes que usted puede estar familiarizado con son 301 Movido Permanentemente, que se utiliza para redirigir sitios web nuevas URLs y 500 Error Interno del Servidor, que es un error que surge con frecuencia cuando algo inesperado ha sucedido en un servidor que lo hace imposible cumplir con la petición prevista.

Con respecto a la API RESTful y sus correspondientes verbos HTTP, todas las respuestas deben ser al rango 2xx.

Solicitud Respuesta
GET 200 (OK)
POST 201 (Creado)
PUT 200 (OK)
DELETE 200 (OK), 202 (Aceptado) o 204 (Sin Contenido)

200 OK es la respuesta que indica que una solicitud tenga éxito. Se utiliza como una respuesta al enviar una solicitud GET o PUT. POST devuelve un 201 Creado para indicar que se ha creado un nuevo recurso y DELETE algunas respuestas aceptables, que transmitan que la solicitud ha sido aceptada (202), o no hay contenido para volver porque el recurso ya no existe (204).

Podemos probar el código de estado de una solicitud de recurso utilizando cURL, que es una herramienta de línea de comandos utilizada para transferir datos a través de URLs. Utilizando curl, seguido por la bandera -i o --include, envíe una petición GET a una URL y mostrar los encabezados y el cuerpo. Podemos comprobarlo abriendo el programa de línea de comandos y prueba de rizo con Google.

Servidor de Google responderá con el siguiente.

Como podemos ver, la petición de curl devuelve varios encabezados y el cuerpo entero del HTML de la respuesta. Puesto que la solicitud fue a través con éxito, la primera parte de la respuesta es el código de 200 estado, junto con la versión de HTTP (esto será HTTP/1.1 o HTTP/2).

Ya que esta petición particular está devolviendo una página web, el content-type (tipo MIME) que se devuelve es text/html. En un API RESTful, probablemente verá application/json para indicar la respuesta JSON.

Curiosamente, podemos ver otro tipo de respuesta introduciendo una URL distinta. Hacer un curl en Google sin la www.

Google redirige a google.com a www.google.com y utiliza una respuesta 301 para indicar que el recurso debe ser redirigido.

REST API Extremos

Cuando se crea una API en un servidor, los datos que contiene están accesibles a través de criterios de valoración. Un endpoint es la URL de la petición que puede aceptar y procesar la solicitud de GET, POST, PUT o DELETE.

Una dirección URL de la API consiste de la raíz, la ruta y la cadena de consulta opcional.

  • Por ejemplo, la Raíz https://api.example.com o https://api.example.com/v2: la raíz de la API, que puede consistir en el protocolo, el dominio y la versión.
  • Ruta por ejemplo, usuarios/ o /usuarios/5: ubicación de los recursos específicos.
  • Consulta de Parámetros (Opcionales) por ejemplo ?location=chicago&age=29: pares de valores clave opcional utilizados para ordenación, filtrado y paginación.
    Podemos poner a todos juntos para implementar algo como el ejemplo de abajo, que devuelve una lista de todos los usuarios y utilice un parámetro de consulta de límite para filtrar las respuestas para incluir sólo diez resultados.

https://api.example.com/users?limit=10

Generalmente, cuando la gente se refiere a una API como un API RESTful, se refieren a las convenciones de nomenclatura que van en la construcción de terminales de dirección URL de la API. Algunos convenios importantes para un estándar API RESTful son los siguientes:

  • Caminos deben ser plurales: por ejemplo, para obtener el usuario con un id de 5, usamos /usuarios/5, no usuario/5.
  • Criterios de valoración no deben mostrar la extensión de archivo: aunque una API muy probablemente regresará JSON, la URL no debe terminar en .json.
  • Endpoints deben usar sustantivos, no verbos: palabras como add y delete no deben aparecer en un REST URL. Para agregar un nuevo usuario, simplemente sería enviar una solicitud POST a /users, no es algo como /users/add. La API debe ser desarrollada para manejar varios tipos de solicitudes a la misma URL.
  • Las rutas distinguen entre mayúsculas y minúsculas, y deben escribirse en minúsculas con guiones en lugar de guiones bajos.

Todos estos convenios son pautas, como no existen estrictos estándares REST a seguir. Sin embargo, utilizando estas guías hará su API consistente, familiar y fácil de leer y entender.

Conclusión

En este artículo, hemos aprendido lo que REST y la API RESTful son, cómo funcionan los códigos de respuesta y métodos de la petición HTTP, la estructura de una URL de la API y convenciones comunes de API RESTful. En el siguiente tutorial vamos a aprender cómo poner toda esta teoría para utilizar al configurar un servidor Express con Node.js y construir nuestra propia API.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.