API RESTful en WordPress
Todas las Aplicaciones Web necesitan una API para poder conectar el front con el back. Analizaremos la API de un CMS muy utilizado a día de hoy, Wordpress; veremos qué son los desarrollos desacoplados, los endpoints por defecto y cómo crear personalizados.
Qué es API Rest y para qué sirve
API es una capa de abstracción (interfaz), un conjunto de reglas que definen cómo realizar las comunicaciones entre dos sistemas, en el ámbito web se podría decir que es un servicio backend utilizado para conectar dos aplicaciones.
Dicha interfaz funciona mediante peticiones y respuestas. El usuario, al utilizar el frontal de la página web envía peticiones al servidor y este responde con todos los datos necesarios para mostrar la información solicitada. Dicha información se obtiene en formato JSON que se transforma para que se vea de una forma más amigable.
REST es un acrónimo de Representational State Transfer o transferencia de estado representacional. Le agrega una capa muy delgada de complejidad y abstracción a HTTP. Mientras que HTTP es transferencia de archivos, REST se basa en la transferencia de recursos. Para que la API se considere Restful debe incluir como mínimo 4 métodos que permitan obtener, crear, actualizar y eliminar objetos. Estos métodos son estándares y se nombran de la siguiente manera: Get, Post Put y Delete, de esta forma y adjuntando a la petición la tarea que se va a realizar el servidor la interpreta y se modifica la base de datos.
Qué es un desarrollo desacoplado (front (ReactJS) y el back (WP) van por libre) se comunican por API Rest
Un desarrollo desacoplado consiste en desarrollar de forma independiente el backend y el frontend. Por ejemplo, se puede dar el caso de desarrollar el backend aprovechando al máximo la API de WordPress y su panel de administración para llevar el control de la página web pero que, sin embargo, el frontal que vean los usuarios del sitio web este desarrollado por ejemplo con un FrameWork como puede ser ReactJS . Esto es posible porque se pueden realizar diseños más dinámicos que si se utilizasen los temas por defecto o temas modificados que hay disponibles en WordPress.
Dicha comunicación entre el front y el back sería posible accediendo a la API de WordPress a través de los endpoints que tiene por defecto o creando los endpoints que nosotros necesitemos si se trata de un desarrollo mas complejo y adaptado a nuestras necesidades. En el punto 3 y 4 podéis ver cómo acceder a los endpoints que ofrece WordPress y cómo crear uno propio adaptándolo a vuestras necesidades.
Endpoint WP por defecto
Al crear un WordPress este genera una serie de endpoints para poder realizar ciertas acciones si se decide utilizar un framework de frontend. A continuación, os dejamos la lista de endpoints que crea junto con la ruta para acceder a ellos:
ENDPOINT |
RUTA |
Posts |
/wp/v2/posts |
Post Revisions |
/wp/v2/revisions |
Categories |
/wp/v2/categories |
Tags |
/wp/v2/tags |
Pages |
/wp/v2/pages |
Comments |
/wp/v2/comments |
Taxonomies |
/wp/v2/taxonomies |
Media |
/wp/v2/media |
Users |
/wp/v2/users |
Post Types |
/wp/v2/types |
Post Statuses |
/wp/v2/statues |
Settings |
/wp/v2/settings |
Pages |
/wp/v2/pages |
Pages Revisions |
/wp/v2/pages/<id>/revisions |
Themes |
/wp/v2/themes |
Search |
/wp/v2/search |
Block Types |
/wp/v2/block-types |
Blocks |
/wp/v2/blocks |
Block Revisions |
/wp/v2/blocks/<id>/autosaves |
Block Render |
/wp/v2/block-render |
Block Directory Items |
/wp/v2/block-directory/search |
Plugins |
/wp/v2/plugins |
*Este listado ha sido obtenido de la página oficial de WordPress.
Cómo crear endpoints propios
Para crear un endpoint personalizado debes dirigirte al functions.php y adjuntar el siguiente snippet de código:
register_rest_route( ‘test/v1’, ‘/idprueba/(?P\d+)’, array(
‘methods’ => ‘GET’,
‘callback’ => ‘dame_ok’,
) );
} );
Lo primero que se hace es crear la ruta a la que haremos las llamadas para conectarnos con nuestro endpoint. En este caso deberemos añadir un parámetro en formato número (en este ejemplo el parámetro se llamara ‘id’) y se usara para comprobar si el parámetro pasado por la url coincide con uno específico inventado para crear la prueba.
La ruta quedaría de la siguiente manera: www.tusitio.com/wp-json/test/idprueba/2. En el methods se indica el tipo de llamada que se va a realizar (GET, POST, PUT, DELETE). Por ultimo, en el callback se pasa la función se se realizara cuando se llame a esa ruta, en este ejemplo la función será dame_ok($data) y dentro de la misma será donde pongamos el código de las acciones que quieres que se realicen una vez hecha la petición a la ruta.
Cómo securizar las llamadas a la API
En la actualidad se emplean dos estándares principalmente para securizar las llamadas a las APIs. Por un lado tenemos JWT, en la practica se trata de emitir un token que en definitiva es una cadena de texto que consta de 3 partes separadas por puntos y codificadas en Base64 como por ejemplo:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4
gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
La primera parte es el header, que se corresponde con el encabezado dónde se indica por lo menos el algoritmo y el tipo de token. La parte intermedia es el payload, en esta parte contiene los datos de usuario y los privilegios que tiene así como la información que queramos añadir y que creamos convenientes. La ultima parte es la signatura, firma que permite verificar la validez del token.
Por otra parte, tenemos el estándar OAuth, este estándar nació del desarrollo de OpenID para Twitter, es un framework de autorización que funciona permitiendo que las aplicaciones accedan limitadamente a las cuentas de usuario de algunos servicios como Facebook, Google…
Si quieres más información sobre API RESTful, no dudes en ponerte en contacto con nosotr@s, estaremos encantad@s de ayudarte.