Utilizando la REST API en la vida real – Parte 1

La REST API se ha convertido en el tema de mayor relevancia en la comunidad de WordPress desde mas o menos el año 2015 cuando se comenzó hablar dentro de WordPress. Sin embargo, ha existido desde hace bastante tiempo y los servicios RESTful son de hecho tan antiguos como el propio Internet.

 

Sabemos que Internet esta compuesto de diferentes ordenadores y servidores interconectados, hablando diferentes idiomas y ejecutando diferentes servicios y procesos. Como tal, se ha desarrollado un protocolo común para permitir que diferentes servicios y procesos se comuniquen entre sí. Tales protocolos se pueden describir como un conjunto de estándares dados que permiten la comunicación de Internet de una manera especifica.

REST API, en sí mismo se encuentra encima de tales protocolos y nos permite facilitar la comunicación entre diferentes servicios y máquinas, nos ayuda a interpretar el intercambio de datos que podría estar en curso entre dos diferentes servicios. Hay muchos otros servicios que hacen el mismo trabajo que REST pero con una diferencia propia. Por ejemplo, JMS es una técnica similar a las aplicaciones Java, mientras que XML-RPC es una metodología capaz y popular pero un poco anticuada y menos segura que puede facilitar la comunicación entre servicios al igual que REST.

Cuales son las ventajas de los servicios REST

En este punto se hace necesario saber ¿que hace que el servicios REST sean mejor que otros? En términos más simples, REST ayuda en el intercambio de datos con un conjunto de mecanismos y protocolos bien establecidos y se centra más en la carga de trabajo mínima, a diferencia de muchos otros métodos similares que son más pesados y voluminosos en términos de operación. Como tal, REST se centra más en la eficiencia y la velocidad y ofrece el intercambio de datos entre plataformas. Esto es la mayor ventaja de usar los servicios RESTful.

Su arquitectura

Como ya lo habíamos mensionado en un artículo anterior de introducción a la REST API la arquitectura de los servicios RESTful es bastante sencilla y podemos resumir brevemente sus principales componentes de la siguiente manera:

• Los recursos son los componentes clave de los servicios RESTful, Se identifican por direcciones URL lógicas y son universalmente accesibles por otras partes del sistema.
• Los recursos deben contener enlaces a otra información, al igual que las páginas web. Por lo tanto los recursos deben estar interconectados.
• Los recursos se pueden almacenar en caché.
• Los sistemas RESTful siguen el modelo cliente-servidor. (Como la mayoría).
• Los servidores proxy HTTP estándar se pueden utilizar en la arquitectura RESTful.
• Los servicios REST pueden interactuar con servicios que no sean REST, y viceversa.

REST es más un estilo que un estándar, por lo que no hay muchos principios de diseño a considerar, en general esto es lo que se debe seguir:

• Las solicitudes GET no deben causar una modificación en el estado o alterar los datos. Si desea modificar el estado o los datos utilice las solicitudes POST.
• La paginación es siempre una buena práctica; si su consulta GET lee las entradas deje que lea el primer número de entradas (por ejemplo, 10) y luego use los enlaces de paginación para leer más entradas.
• Las URL físicas se consideran una mala práctica, y las URL lógicas deben ser la primera opción.
• Si la respuesta REST está en XML considere el uso de un esquema (schema).

Ahora que tenemos mas claros los términos REST API y JSON realicemos algunos ejemplos comparativos entre la arquitectura SOAP y REST para comprar.

Como pasamos comandos en SOAP

Ej, Digamos que necesitamos consultar una base de datos determinada para los detalles de usuario con ID 0100, utilizando servicios web y SOAP (Simple Object Access Protocol), haremos algo como lo siguiente:

<?xml version="1.1"?>
<soap:Envelope
xmlns:soap="http://www.w3.org/2001/12/soap-envelope";
soap:encodingStyle="http://www.w3.org/2001/12/soap-encoding">;
<soap:body pb="http://www.example.com/database">;
<pb:GetUserDetails>
<pb:UserID>0100</pb:UserID>
</pb:GetUserDetails>
</soap:Body>
</soap:Envelope>

El código anterior nos dará un archivo XML incrustado dentro de un sobre de respuesta SOAP.

Como pasamos comandos en REST

Si usamos REST seguramente sería mas sencillo quedando algo mas o menos así:

http://www.example.com/database/UserDetails/0100

Así de sencillo, con una solicitud GET es una simple URL y la respuesta nos dará los datos sin procesar, es decir, los detalles del usuario con ID 0100. Mientras que con SOAP, necesitamos múltiples datos para analizar la respuesta, en REST sólo necesitamos pasar una URL. Incluso podemos probar la API directamente en el navegador como una simple solicitud.

Como manejamos los datos en REST

El anterior ejemplo es bastante sencillo pero tampoco cambia mucho cuando deseamos realizar operaciones mas complejas, la lógica sigue siendo la misma. Vamos a refinar la consulta anterior y a buscar el usuario con el nombre Andres y apellido Vega de la siguiente manera:

http://www.example.com/database/UserDetails?firstName=Andres&lastName=Vega

Como podemos ver para parámetros más largos incluimos los parámetros dentro de la URL de la petición HTTP POST y en este caso utilizando el símbolo & para separar cada consulta.

Para consultas más simples solo necesitamos GET para leer y es el debemos de utilizar. Sin embargo, para las consultas de sólo lectura que son de naturaleza compleja las solicitudes POST también pueden utilizarse, por supuesto las solicitudes POST también se utilizan para consultas que pueden cambiar el estado de los datos y tratar con la creación, actualización y eliminación de estos.

Como tal, REST se centra más en la eficiencia y la velocidad y ofrece el intercambio de datos entre plataformas.

En términos de respuestas del servidor los servicios RESTful pueden manejar diferentes formatos dentro de los cuales están XML, CSV y JSON. Cada uno de estos formatos tiene sus propias ventajas por ejemplo: XML es bastante fácil de expandir, CSV es compacto y ligero, mientras que JSON es fácil de analizar o leer. Como ya habrás visto para la API REST de WordPress JSON es el camino a seguir, todo gracias a JavaScript.

Recuerda que este es el siguiente capítulo de los artículos donde explico la REST API, puedes mirar el primero de introducción en la siguiente url: La REST API de WordPress – Introducción