Restricciones arquitectónicas de la API REST

REST significa Transferencia de estado representacional y API significa Interfaz de programa de aplicación. REST es un estilo de arquitectura de software que define el conjunto de reglas que se utilizarán para crear servicios web. Los servicios web que siguen el estilo arquitectónico REST se conocen como servicios web RESTful. Permite que los sistemas solicitantes accedan y manipulen recursos web mediante el uso de un conjunto uniforme y predefinido de reglas. La interacción en los sistemas basados ​​en REST ocurre a través del Protocolo de transferencia de hipertexto (HTTP) de Internet.

Un sistema Restful consta de:

• cliente que solicita los recursos.
• servidor que tiene los recursos.

Es importante crear una API REST de acuerdo con los estándares de la industria, lo que facilita el desarrollo y aumenta la adopción por parte del cliente.

Restricciones arquitectónicas de la API RESTful: Hay seis restricciones arquitectónicas que hacen que cualquier servicio web se enumere a continuación:

• Interfaz uniforme
• Apátrida
• almacenable en caché
• Servidor de cliente
• Sistema en capas
• Código bajo demanda

La única restricción opcional de la arquitectura REST es el código bajo demanda. Si un servicio viola cualquier otra restricción, no se puede denominar estrictamente como RESTful.

Interfaz uniforme: es una restricción clave que diferencia entre una API REST y una API que no es REST. Sugiere que debería haber una forma uniforme de interactuar con un servidor determinado, independientemente del dispositivo o tipo de aplicación (sitio web, aplicación móvil).
El principio de cuatro directrices de la interfaz uniforme es:

• Basado en recursos: los recursos individuales se identifican en las requests. Por ejemplo: API/usuarios.
• Manipulación de recursos a través de representaciones: el cliente tiene la representación del recurso y contiene suficiente información para modificar o eliminar el recurso en el servidor, siempre que tenga permiso para hacerlo. Ejemplo: por lo general, el usuario obtiene una identificación de usuario cuando el usuario solicita una lista de usuarios y luego usa esa identificación para eliminar o modificar ese usuario en particular.
• Mensajes autodescriptivos: cada mensaje incluye suficiente información para describir cómo procesar el mensaje para que el servidor pueda analizar fácilmente la solicitud.
• Hypermedia as the Engine of Application State (HATEOAS): debe incluir enlaces para cada respuesta para que el cliente pueda descubrir otros recursos fácilmente.

Sin estado: significa que el estado necesario para manejar la solicitud está contenido dentro de la solicitud misma y el servidor no almacenaría nada relacionado con la sesión. En REST, el cliente debe incluir toda la información para que el servidor cumpla con la solicitud, ya sea como parte de los parámetros de consulta, encabezados o URI. La falta de estado permite una mayor disponibilidad ya que el servidor no tiene que mantener, actualizar o comunicar ese estado de sesión. Existe un inconveniente cuando el cliente necesita enviar demasiados datos al servidor, por lo que reduce el alcance de la optimización de la red y requiere más ancho de banda.

Almacenamiento en caché: cada respuesta debe incluir si la respuesta se puede almacenar en caché o no y durante cuánto tiempo se pueden almacenar en caché las respuestas en el lado del cliente. El cliente devolverá los datos de su caché para cualquier solicitud posterior y no habrá necesidad de enviar la solicitud nuevamente al servidor. Un almacenamiento en caché bien administrado elimina parcial o completamente algunas interacciones cliente-servidor, mejorando aún más la disponibilidad y el rendimiento. Pero en algún momento hay posibilidades de que el usuario reciba datos obsoletos.

Cliente-Servidor: la aplicación REST debe tener una arquitectura cliente-servidor. Un Cliente es alguien que solicita recursos y no se preocupa por el almacenamiento de datos, que permanece interno en cada servidor, y el servidor es alguien que tiene los recursos y no se preocupa por la interfaz de usuario o el estado del usuario. Pueden evolucionar de forma independiente. El cliente no necesita saber nada sobre la lógica empresarial y el servidor no necesita saber nada sobre la interfaz de usuario de la interfaz de usuario.

Sistema en capas: una arquitectura de aplicación debe estar compuesta de múltiples capas. Cada capa no sabe nada sobre ninguna capa que no sea la capa inmediata y puede haber muchos servidores intermedios entre el cliente y el servidor final. Los servidores intermediarios pueden mejorar la disponibilidad del sistema al permitir el equilibrio de carga y al proporcionar cachés compartidos.

Código bajo demanda: Es una característica opcional. Según esto, los servidores también pueden proporcionar código ejecutable al cliente. Los ejemplos de código bajo demanda pueden incluir los componentes compilados, como applets de Java y scripts del lado del cliente, como JavaScript.

Reglas de la API REST: hay ciertas reglas que deben tenerse en cuenta al crear puntos finales de la API REST.

• REST se basa en el recurso o el sustantivo en lugar de la acción o el verbo. Significa que un URI de una API REST siempre debe terminar con un sustantivo. Ejemplo: /api/users es un buen ejemplo, pero /api?type=users es un mal ejemplo de creación de una API REST.
• Los verbos HTTP se utilizan para identificar la acción. Algunos de los verbos HTTP son: GET, PUT, POST, DELETE, UPDATE, PATCH.
• Una aplicación web debe organizarse en recursos como usuarios y luego usar verbos HTTP como: GET, PUT, POST, DELETE para modificar esos recursos. Y como desarrollador, debe quedar claro lo que se debe hacer con solo mirar el punto final y el método HTTP utilizado.
  

  URI	verbo HTTP	Descripción
  api/usuarios	OBTENER	Obtener todos los usuarios
  api/usuarios/nuevo	OBTENER	Mostrar formulario para agregar nuevo usuario
  api/usuarios	CORREO	Agregar un usuario
  api/usuarios/1	PONER	Actualizar un usuario con id = 1
  api/usuarios/1/editar	OBTENER	Mostrar formulario de edición para el usuario con id = 1
  api/usuarios/1	ELIMINAR	Eliminar un usuario con id = 1
  api/usuarios/1	OBTENER	Obtener un usuario con id = 1

• Utilice siempre plurales en la URL para mantener un URI de API coherente en toda la aplicación.
• Envíe un código HTTP adecuado para indicar un estado de éxito o error.

Nota: Puede usar GET y POST fácilmente, pero para usar PUT y DELETE necesitará instalar la anulación del método. Puede hacer esto siguiendo el siguiente código:

npm install method-override --save

Esto simplemente requiere este paquete en su código escribiendo:

var methodOverride = require("method-override");

Ahora puede usar fácilmente las rutas PUT y DELETE:

app.use(methodOverride("_method"));

Verbos HTTP: algunos de los métodos/verbos HTTP comunes se describen a continuación:

• GET: Recupera uno o más recursos identificados por la URI de solicitud y puede almacenar en caché la información recibida.
• POST: cree un recurso a partir del envío de una solicitud y la respuesta no se puede almacenar en caché en este caso. Este método no es seguro si no se aplica seguridad al punto final, ya que permitiría a cualquier persona crear un recurso aleatorio mediante el envío.
• PUT: actualiza un recurso existente en el servidor especificado por el URI de solicitud.
• ELIMINAR: elimina un recurso existente en el servidor especificado por el URI de la solicitud. Siempre devuelve un estado HTTP apropiado para cada solicitud.
• Los métodos GET, PUT, DELETE también se conocen como métodos idempotentes. Aplicar una operación una vez o aplicarla varias veces tiene el mismo efecto. Ejemplo: elimine cualquier recurso del servidor y lo logra con 200 OK y luego intente nuevamente eliminar ese recurso y mostrará un mensaje de error 410 GONE.