Estos conceptos están muy relacionados sí, pero no son lo mismo, veamos qué es cada uno de ellos y luego los relacionaremos a todos, de esta forma la romperás en alguna entrevista que te pregunten sobre estos términos, y cuando te toque diseñar una arquitectura en backend para por ejemplo un API ya sabrás exactamente que es cada cosa y podrás aplicarla con propiedad crack, como debe ser 😉

API

Si lo sacamos del libro viene a ser Application Programming Interface, de ahí vienen las siglas, pero definámoslo de una manera más entendible sin perder la rigurosidad tampoco, no se me relajen.

Un API es un conjunto de funcionalidades o recursos que nos expone un sistema para poder interactuar con él desde otro sistema, esto sin importar ni los lenguajes de programación en que cada uno de ellos esté escrito ni la tecnología ni nada, y esto es gracias a que trabaja con una capa de abstracción.

Podemos ver un ejemplo para entender mejor el concepto, el API de un banco, que nos va a exponer sus servicios, digamos de hacer un checkout de una compra online, entonces de esta forma desde nuestra aplicación por ejemplo una App Android puede ejecutar una función en nuestra cuenta bancaria utilizando el API que el mismo banco nos provee, sin que nos de el código ni detalles técnicos de cómo lo hace, ya que eso no nos importa, aquí un ejemplo del API del banco Colombiano Bancolombia.

Si quieres profundizar, te invito a leer esta entrada anterior, cosecha de la casa.

En la Web hay varios API para hacer pruebas o maquetar frontend, te listo algunos para que puedas jugar con ella y hacer pruebas, dale sin miedo, estropeando aprendes, igual nada malograrás porque son precisamente para experimentar 😄

• https://rickandmortyapi.com/
• https://swapi.dev/
• https://jsonplaceholder.typicode.com/

REST

Sus siglas vienen de Representational State Transfer, es un estilo de arquitectura de software para realizar una comunicación cliente-servidor. Se apoya en el protocolo HTTP para la comunicación al servidor y los mensajes que se envían y reciben pueden estar en XML o JSON del cual abordaremos más abajito.

Este estilo de arquitectura fue propuesto por Roy Fielding en su tesis, vaya que hizo buen trabajo, sin duda fue otro crack 🤣.

REST es la contrapartida a SOAP, a mi modesto entender es mucho mejor y más sencillo y versátil.

Las peticiones que le hacemos al servidor son clasificadas mediante lo conocido como verbos HTTP y pueden ser:

GET

Nos permite obtener recursos del servidor como la lista de cuentas bancarias que el usuario Pepe el Grillo tiene.

POST

Inserta un recurso nuevo, por ejemplo usando el API de Netflix guardamos una nueva película en nuestra lista de favoritos.

PUT

Actualiza un recurso en el servidor, por ejemplo queremos actualizar nuestros datos personales usando el API de nuestro banco.

PATCH

Hace una actualización parcial, a diferencia del PUT en el que debemos enviar todo porque actualizará todo con lo que le enviemos y si dejamos de enviarle algún campo le pondrá como valor vacío si la lógica del negocio lo permite. Por ejemplo quiero actualizar mi correo de recuperación de mi servicio de mensajería Gmail.

DELETE

Borra un recurso en el servidor, por ejemplo con el API de una plataforma como Youtube quiero eliminar una lista de reproducción.

• HEAD
• CONNECT
• OPTIONS
• TRACE

Los más utilizados son los primeros cinco de la lista, pero igual te sirve como cultura general conocerlos todos, más detalle aquí.

Principios de REST

• Interfaz uniforme: Esta basado en recursos y estos deben ser sustantivos en plural por ejemplo: libros, alumnos, peliculas, etc.
• Stateless: REST no tiene estados, esto quiere decir que una llamada al API es independiente de otra llamada y no depende de ella, sin embargo sí se puede usar caché para reducir el tiempo de espera en consultas GET.
• Operaciones específicas: Cada acción u operacion sobre un recurso está bien definido y tiene un claro propósito, no es "multifuncional" si un endpoint por ejemplo es para insertar nuevos clientes, no debería también insertar pedidos.
• Sintaxis estandarizada: Cada recurso es accesibe únicamente desde su URI.
• Cliente-Servidor: El servidor hace el procesamiento del API y expone los recursos a uno o muchos clientes, que pueden ser una aplicación de escritorio, una página web, etc. El cliente debe ser independiente del servidor y toda comunicación a él se debe dar mediante el API.

RESTful | API RESTful

Así como REST es el estilo de Arquitectura, RESTful es la implementación de dicha arquitectura.

Entonces por simple sentido común un API RESTful es un API que fue diseñada usando la arquitectura REST. Así de sencillo estimados, no hay por qué complicarse más.

JSON

Es un formato de texto para intercambio de datos, este formato es que utilizan los API RESTful fue especificada por Douglas Crockford. Se ve así:

[
  {
    "postId": 1,
    "id": 1,
    "name": "Json is cool",
    "email": "Eliseo@gardner.biz",
    "body": "laudantium enim quasi est quidem magnam voluptate ipsam eos"
  },
  {
    "postId": 1,
    "id": 2,
    "name": "Bravedeveloper is cool too",
    "email": "Jayne_Kuhic@sydney.com",
    "body": "est natus enim nihil est dolore omn"
  }
]

Entonces quiere decir que...

Un API que usa la arquitectura REST se le llama API RESTful la cual emplea el formato de texto JSON para intercambiar datos, ya no dudarás cuando te pregunten por estos conceptos y cuando te toque diseñar un API lo harás como un dev seguro.

Listo genios, es lo que quería compartir con ustedes, ahora si esta entrada te aportó valor compártela 😊