REST en breve

Objetivos

Cubre los siguientes objetivos de la asignatura

  1. Conocer los conceptos relacionados con el proceso de virtualización tanto de software como de hardware y ponerlos en práctica.

Objetivos específicos

  1. Entender los conceptos necesarios para diseñar, implementar y construir una aplicación sobre infraestructura virtual.
  2. Diseñar, construir y analizar las prestaciones de una aplicación en infraestructura virtual.

Los sistemas REST (Representational State Transfer) usan la sintaxis y semántica del protocolo HTTP tanto para llevar a cabo peticiones a un microservicio o una función en un marco serverless.

Las peticiones HTTP tienen varias partes diferenciadas:

Aunque hay 10 comandos HTTP diferentes, en realidad los que más se usan son sólo cuatro. Se distinguen por su idempotencia (la repetición de un comando sobre un URI dará el mismo resultado) y seguros (cuando no realizan ningún cambio de estado).

Lo anterior son convenciones, y lo que se ejecute por omisión dependerá en realidad de la persona que lo implemente.

En muchos casos PUT y POST se usan de forma intercambiable. Son muy diferentes, sin embargo: aquí se muestran diferencias que van desde poder ser cacheables (o no) hasta el significado del URI que se vaya a usar. En una petición PUT, el URI que se usa es el que se va a crear. En un POST, es simplemente un punto que va manejar la petición. Por eso PUT se suele usar para crear (y modificar, siempre que la petición contenga la nueva versión) mientras que POST se puede usar para crear (siempre que sea un URI genérico) o modificar parte de un recurso.

La respuesta HTTP tendrá una estructura similar, pero incluirá también códigos de estado HTTP. Estos códigos de estado pueden incluir códigos de error, que tendremos que interpretar desde nuestra aplicación; los códigos 500 (error del servidor) no serán códigos que podamos tratar, en general, desde nuestra aplicación, porque indican que ha habido una excepción no capturada en la misma.

Es conveniente conocer esta estructura general del protocolo HTTP, porque se aprovechará para escribir APIs que usen su semántica tanto para las peticiones como para las respuestas. En estas, diferentes frameworks ofrecerán un API que permitirá trabajar fácilmente con las cabeceras, los contenidos y los metadatos correspondientes.

A dónde ir desde aquí

En el siguiente tema veremos cómo se usan estas cabeceras para estructurar peticiones.