Oscar Sánchez Jara ( @dev_lusaja )

Contenido

  • Introducción a HTTP y REST
  • ¿Por qué usar REST?
  • Single Page Application (overview)
  • Referencias

¿Qué es HTTP?

HTTP es un protocolo que se sitúa al nivel de aplicación, está diseñado para ser ejecutado sobre TCP o sobre transporte seguro TLS/SSL

 

El mensaje de petición en HTTP consta de una primera línea de texto indicando la versión del protocolo, el verbo HTTP y la URI destino.

 

Los mensajes de respuesta HTTP siguen el mismo formato que los de petición, excepto en la primera línea, donde se indica el código de respuesta junto a una explicación textual de dicha respuesta.

Introducción a HTTP y REST

Introducción a HTTP y REST

/* PETICION */

POST /servicios/pago HTTP/1.1
Host: www.aplicacion.pe
Content-Type: application/x-www-form-urlencoded
Accept: application/json
Accept-Encoding:gzip,deflate,sdch
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive


/* RESPUESTA */

HTTP/1.1 201 Created

Content-Type: application/json;charset=utf-8
Location: https://www.aplicacion.pe/servicios/pago/3432
Cache-Control:max-age=21600
Connection:close
Date:Mon, 23 Jul 2017 14:20:19 GMT
ETag:"2cc8-3e3073913b100"
Expires:Mon, 23 Jul 2017 20:20:19 GMT
{
"id":"https://www.aplicacion.pe/servicios/pago/3432",
"estado": "pendiente"
}

Ejemplo de cabeceras HTTP

¿Qué es rest?

Su nombre significa Transferencia de Estado Representacional.

REST es un estilo arquitectónico que brinda un conjunto de restricciones a respetar cuando diseñamos la arquitectura de nuestros servicios web.

Roy Thomas Fielding en su tesis: "Estilos Arquitecturales y el Diseño de Arquitecturas de Software basadas en Red" describe como un enfoque para desarrollar servicios web y una alternativa a otras especificaciones de computación distribuida tales como CORBA o DCOM.

 

Introducción a HTTP y REST

 

Algunas de las restricciones propuestas por REST son las siguientes:

    1. Una URI especifica un recurso (entidad del negocio).

    2. La URI debe definir al recurso usando un sustantivo, no se debe             usar verbos.

    3. El sustantivo utilizado se debe pluralizar.

    4. Se debe colocar la versión del servicio en la Base de la URI.

https://aplicacion.pe/api/v1/pagos

Introducción a HTTP y REST

Introducción a HTTP y REST

  4. Utilizar los verbos HTTP para operar sobre los recursos.

Metodo Seguro Idempotente Semantica
GET SI SI Leer estado de un recurso
HEAD SI SI Leer las cabeceras del recurso
PUT NO SI Crear o modificar un recurso
DELETE NO SI Eliminar un recurso
POST NO NO Cualquier acción generica
OPTION SI SI Listar los metodos permitidos por el recurso

Introducción a HTTP y REST

  5. Cada recurso posee un identificador único universal (UUID o GUID).


UUID v1: 2ce14aae-52b8-11e7-b114-b2f933d5fe66 (usa la mac address)

UUID v4: 9be8f1bd-dd0e-47ec-a0b4-0d4bc4f2ed9b (Open Source)

GUID:    1a723c13-35f1-41d1-b716-89e8a9dda34a (Microsoft)

  6. Las operaciones se realizan mediante la transferencia del estado          del recurso entre cliente y servidor, esto quiere decir que el request          enviado por el cliente tiene toda la información necesaria para                    satisfacer un requerimiento.

Introducción a HTTP y REST

    7. Uso de Hipermedios (principio HATEOAS).


[
    {
        "id":"https://www.aplicacion.pe/servicios/pago/3432",
        "estado": "pendiente"
    },
    {
        "id":"https://www.aplicacion.pe/servicios/pago/3433",
        "estado": "activo"
    }

]

El principio de HATEOAS nos dice que un recurso debe brindarte información para descubrir nuevos recursos.

Introducción a HTTP y REST

    8. La respuesta enviada desde el servidor debe tener formato JSON.

 

    9. El servicio RESTful no envía contenido HTML para renderizar en el       Cliente.

        REST es el modelo arquitectónico.

        RESTful es una aplicación web que emplea la arquitectura REST.

 

    10. Utilizar los códigos HTTP de manera correcta.

Introducción a HTTP y REST

¿Por qué usar rest?

Ventajas

  • Separación de funcionalidades entre cliente y servidor.
  • Escalabilidad.
  • Independencia de tecnologías y/o lenguajes.
  • Esta arquitectura esta pensada para aplicaciones escalables, no es recomendable utilizarla si solo se hará una web estática.

 

Desventajas

  • Al principio puede incurrir en tiempos de desarrollo ya que se debe montar toda la arquitectura base para la API REST.
  • No se manejan estados almacenados en el servidor, esto se soluciona utilizando autenticación por TOKENS.

¿Por qué usar REST?

Single Page application (SPA)

Es una aplicación web diseñada con la finalidad de dar una experiencia más fluida a los usuarios.

En un SPA todos los recursos necesarios (HTML, CSS, JS) son cargados al iniciar la pagina con la finalidad que la pagina no tenga que volver a cargar otra vez al moverse a través  de ella.

Algunos frameworks para trabajar este tipo de aplicaciones son: Angular, Vuejs.

Single Page Application

REFERENCIAS

  • https://es.wikipedia.org/wiki/Hypertext_Transfer_Protocol
  • https://github.com/WhiteHouse/api-standards
  • https://www.w3.org/2001/sw/wiki/REST
  • https://www.genbetadev.com/formacion/entendiendo-el-principio-hateoas
  • http://www.odata.org/
  • Principios de Diseño de APIs REST - Enrique Amodeo
  • https://httpstatuses.com/
  • https://restfulapi.net/
Made with Slides.com