APIS REST

Por pispate

APIS REST

Vamos a hablar del concepto de APIs REST. Para ello primero hemos de ver lo que significa API y REST.

API (Application Programming Interface o Interfaz de Programación de Aplicaciones. ) es el conjunto de subrutinas, funciones y procedimientos (o métodos, en la programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por otro software como una capa de abstracción.

Qué es API: Digamos que una API es como un servicio web de un tercero que contiene funciones ya preparadas y que, gracias a que ese tercero nos lo facilita, nosotros podemos usar de una manera segura para simplificar nuestras tarea. Como ejemplos de APIs tenemos a Google maps, facebook connect, twitter, etc.. O bien podemos crear nosotros mismos una API que pueda ser usada por un tercero.

Qué es REST: Según la wikipedia, La Transferencia de Estado Representacional (Representational State Transfer) o REST es una técnica de arquitectura software para sistemas hipermedia distribuidos como la World Wide Web es un tipo de arquitectura de desarrollo web que se apoya totalmente en el estándar HTTP. En palabras entendibles REST es algo que nos permite crear servicios y aplicaciones que pueden ser usadas por cualquier dispositivo o cliente que entienda HTTP. REST es parecido a un framework con el que puedes crear aplicaciones web para el estandar HTTP.

Digamos que REST es una de las mejores herramientas para crear APIs para servicios de Internet.

Como resumen y para entenderlo mejor: Una api rest es un backend (creado en php, o en el lenguaje que sea, o con un framework de algún lenguaje) con una serie de urls que se preparan para devolvernos datos o para insertar datos. Generalmente recibirá o enviará los datos en el formato JSON. Por ejemplo el login de un usuario, los usuarios de tal provincia, etc.. Tú creas en tu backend una serie de urls por ejemplo www.site.com/getUser y si entramos ahí con cualquier cosa que siga el protocolo http podemos obtener los datos de un usuario (que tenemos almacenados en una base de datos) en formato json (o el que sea) y se muestra en pantalla (en el caso de abrir la url con un navegador por ejemplo). Y lo mismo pero al revés, podemos enviar a una url de ese backend datos en formato JSON (generalmente) y el backend se encarga de introducirlos en la base de datos por ejemplo o de hacer lo que sea.

Actualmente es importante usar API REST porque el mismo backend sirve para una web, para una aplicacion en android, en IOS, para un frontend creado con react o con angular o como ya hemos dicho, con cualquier cosa que use el protocolo http. Trabajas una sola vez en el backend y luego esto lo aprovecha cualquier otra cosa (ya no hay que crear el mismo backend para cada cosa que lo utilice). Antes el backend y el frontend se programaban juntos para una web, ahora se tiende a hacer un backend estilo API REST y ya queda para ser usado con lo que sea. Una web, un framework frontend, etc sin tener que adaptarlo. Espero haya quedado claro. Actualmente están muy de moda aislar el frontend del backend porque han salido muchos frameworks de javascript estilo angular. Mediante peticiones ajax vamos obteniendo los resultados y de una manera mucho más rapida.

A la hora de usar REST hay que tener en cuenta lo siguiente:

1: Uso correcto de URIs

Las reglas básicas para construir las uris son:

  • Los métodos HTTP, que son: GET: Para consultar y leer recursos, POST: Para crear recursos, PUT: Para editar recursos, DELETE: Para eliminar recursos, PATCH: Para editar partes concretas de un recurso.
  • Códigos de estado: Cuando realizamos una operación, es vitar saber si dicha operación se ha realizado con éxito o en caso contrario. Los códigos de error y códigos de estado nos proporcionan esto y lo mejor es usar los standar.
  • Aceptación de tipos de contenido: HTTP nos permite especificar en qué formato/s queremos recibir el recurso usando el header Accept (ej: Accept: application/epub+zip , application/pdf, application/json). Nuestra API devolverá el recurso en el primer formato disponible, si no el segundo, etc y si no devolverá el código de estado HTTP 406. La respuesta será por ejemplo: Content-Type: application/pdf.

2: Hypermedia.

Que es conectar mediante vínculos las aplicaciones clientes con las APIs. Para ello se usan las cabeceras Accept y Content-Type, para que tanto el cliente como la API, sepan que están hablando hypermedia. Por ejemplo si el cliente solicita el formato application/epub+zip de forma preferente al formato application/pdf, le indica al servicio web, que entiende su formato hypermedia y puede aprovecharlo. El servicio web que implementa también hypermedia, le devuelve la información de recurso y la información de hypermedia que puede utilizar el cliente.

Además de estas reglas:

Nunca se debe guardar estado en el servidor, toda la información que se requiere para mostrar la información que se solicita debe estar en la consulta por parte del cliente. Al final todo pasa por conocer HTTP

comentarios en facebook

1 comentarios

anónimo

Por anónimo el 28/08/2019 / #78

y la segunda regla?

1 comentarios
Escribe un comentario como anónimo

Si no quieres comentar como anónimo, puedes Entrar con tu cuenta

Introduce el código

Otros artículos

Siguenos en

Pincha en Me Gusta