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.

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

1: Uso correcto de URIsLas 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: En las URLs, vimos que no era correcto indicar el tipo de formato de un recurso al cual queremos acceder o manipular. 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.

3: 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.

4: Además de estas tres 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

0 comentarios

0 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