• Inicio
  • Iniciar sesión
  • Crear cuenta
  • Explorar cursos
  • Bootcamps
  • Precios
  • Blog

¡Califica el Curso Profesional de Backend!

Selecciona la calificación de 1 a 5 estrellas

Reporta un error

Curso Curso Profesional de Backend

Video Verbos Http en REST

Tipo de error

Algo salió mal al cargar el vídeo

El vídeo no pudo cargarse, hemos enviado un reporte al equipo de desarrollo, para poder solucionarlo a la brevedad.

Mientras solucionamos el problema, intenta lo siguiente para solucionar el error:

  • Recarga la página
  • Intenta reiniciar tu navegador y luego vuelve a reproducir el vídeo
  • Vacía el caché de tu navegador
  • Intenta reproducir con las extensiones del navegador deshabilitadas
  • Intenta con un navegador distinto
  • Si el problema persiste contáctanos en Discord
home Ir al inicio report_problem Reportar falla star Valorar curso

Estas son algunas reglas que te servirán para saber cómo y cuándo debes usar los verbos Http en una arquitectura REST.

Los verbos Http involucrados en un sistema REST son GET, POST, PUT, PATCH y DELETE.

GET es el más simple de todos, es el que usamos para obtener un recurso. Las peticiones GET no deben causar efectos secundarios en un servidor, no deben producir nuevos registros, ni modificar los ya existentes. A esta cualidad la llamamos idempotencia, cuando una acción ejecutada un número indefinido de veces, produce siempre el mismo resultado.

Esto quiere decir, que no importa cuántas veces hagamos una petición GET, los resultados obtenidos serán los mismos.

Cuando ingresamos a la dirección usando GET https://codigofacilito.com/cursos/backend-profesional/ estamos solicitando que se nos entregue el recurso identificado por /cursos/backend-profesional, este es un buen ejemplo de uso con GET.

Esta otra ruta: https://codigofacilito.com/cursos/recomendar?selected_level=0&category_options=28 aunque más compleja, también es correcta, estamos solicitando los recursos identificados por /cursos con las opciones ahí indicadas. Sin importar cuantas veces hagamos esta solicitud, no modificará los resultados por sí misma.

Las peticiones con POST son para crear recursos nuevos, no para eliminarlos, ni para modificarlos. Cada llamada con POST debería producir un nuevo recurso.

Lo que es interesante acerca de POST no es el verbo en sí, queda muy claro que es para crear, más bien es los recursos a los que se dirige.

Por ejemplo, si en nuestra aplicación existe una colección de cursos, la solicitud para crear uno nuevo, debe ser con el verbo POST al recurso que identifica la colección, por ejemplo /cursos.

Si queremos crear un nuevo artículo, pudiéramos tener una URI /articulos. Lo que es importante en estos casos, es recordar que la URI no debe decir qué acción estamos ejecutando, nos olvidamos de /articulos/crear o de /cursos/agregar, etc. El verbo dice qué haremos, y la URI sobre qué recurso se harán las modificaciones.

Algunos escenarios más complejos para el uso de POST son los inicios de sesión, agregar a un carrito de compras, procesar un pago nuevo, etc.

Consideremos por ejemplo el inicio de sesión, normalmente al iniciar sesión, no producimos un nuevo registro en la base de datos, sin embargo, usamos POST porque estamos creando una sesión nueva. Esto nos da a entender que para saber si usaremos POST o no, no necesariamente tenemos que agregar registros en la base de datos, el recurso creado puede ser de otros tipos, como una sesión.

Los verbos PUT/PATCH van como el señor cara de papa y la señora cara de papa, siempre juntos. Los agrupamos porque ambos indican una modificación en el servidor.

En la teoría, PUT se diferencía de PATCH, en que el primero indica que vamos a sustituir por completo un recurso, mientras que PATCH habla de actualizar algunos elementos del recurso mismo, sin sustituirlo por completo.

Un escenario común para el uso de PUT sería una llamada para actualizar la información de un curso, por ejemplo:

PUT /cursos/backend-profesional

O también:

PATCH /cursos/backend-profesional

En la práctica, no conozco un framework que establezca una diferencia en funcionamiento para peticiones con PUT o con PATCH, ambos verbos son tratados como iguales.

Por último, DELETE es el verbo que usamos para eliminar registros, bien pudiera ser para eliminar un recurso con un mensaje Http como

DELETE /cursos/backend-profesional

O para eliminar una colección completa:

DELETE /cursos

Esta es la manera a través de la que usamos los verbos Http en una aplicación web. Estos en combinación con las URIs proveen la interfaz uniforme de la que hablamos cuando discutimos las características de un sistema REST.

Como podrás notar, el beneficio de estas es que se establece una guía para la construcción de la aplicación, las rutas siempre representan recursos, las acciones se representan con Http.

  • check_circle_outline
    Módulo 1 | 8 clases

    Introducción

    expand_more
  • check_circle_outline
    Módulo 2 | 19 clases

    Http

    expand_more
  • check_circle_outline
    Módulo 3 | 11 clases

    Bases de Datos

    expand_more
  • check_circle_outline
    Módulo 4 | 24 clases

    Buenas prácticas de desarrollo.

    expand_more
    • done_all

      Clase 1

      Presentación del bloque

    • done_all

      Clase 2

      Qué es el MVC

    • done_all

      Clase 3

      Organizar un proyecto MVC

    • done_all

      Clase 4

      Qué son las migraciones

    • done_all

      Clase 5

      CLI de Sequelize

    • done_all

      Clase 6

      Generando migraciones

    • done_all

      Clase 7

      Modelos

    • done_all

      Clase 8

      Controladores

    • done_all

      Clase 9

      Vistas

    • done_all

      Clase 10

      Seeders

    • done_all

      Clase 11

      Integrando todo

    • done_all

      Clase 12

      Qué es REST

    • done_all

      Clase 13

      REST en la práctica

    • done_all

      Clase 14

      Verbos Http en REST

    • done_all

      Clase 15

      Rutas REST en Express

    • done_all

      Clase 16

      Crear nuevos registros

    • done_all

      Clase 17

      Formularios

    • done_all

      Clase 18

      Mostrar registros

    • done_all

      Clase 19

      Vistas para todos los registros

    • done_all

      Clase 20

      Identificadores únicos

    • done_all

      Clase 21

      Consulta individual de recursos

    • done_all

      Clase 22

      Actualizar registros

    • done_all

      Clase 23

      Formularios con PUT, PATCH y DELETE

    • done_all

      Clase 24

      Eliminar registros

  • check_circle_outline
    Módulo 5 | 14 clases

    Autenticación

    expand_more
  • check_circle_outline
    Módulo 6 | 14 clases

    Relaciones en la base de datos.

    expand_more
  • check_circle_outline
    Módulo 7 | 5 clases

    Websockets (realtime)

    expand_more
  • check_circle_outline
    Módulo 8 | 4 clases

    Entorno de producción

    expand_more
  • check_circle_outline
    Módulo 9.-

    Examen del curso

    expand_more
    • done_all

      Examen

      Examen final del curso

3 comentario(s)

@egranados13

16 Abril 20

more_vert
  • Resuelta
Hola ,  respecto a lo que  mencionabas  un video pasado sobre  la introduccion de REST en 2010 aprox,  si no mal recuerdo antes de  esto ya podia  hacer  un "submit" de  un formulario en una  pagina  html  donde , la  seguiente  pagina  tomaba  los  valores del mismo via POST (y por  otro lado se  podían , aunque  de  manera  insegura, enviar  cadenas  por  URL  y extraerlas  con GET). ¿En este  punto , este  concepto de  POST ya  era  parte de  REST? o fue  digamos  uno de  los  detonantes  para  extender sus  posibilidades al añadir  mas  verbos ? Saludos, excelente curso!

Jose Valencia

25 Junio 19

more_vert
  • Resuelta

Consideremos por ejemplo el inicio de sesión, normalmente al iniciar sesión, no producimos un nuevo registro en la base de datos,

Pero si se quisiera tener un registro de inicio de sesiones en una tabla?

Ver respuestas (3)

Fernando Hernandez

24 Diciembre 18

more_vert
  • Resuelta
Cuando queremos guardar o almacenar las sesiones de un usuario cada vez que ingresa a nuestra aplicación, es necesario tener una tabla en tu base de datos para que se guarden ahí las sesiones?
Ver respuestas (1)

Verbos Http en REST

arrow_back Siguiente arrow_forward
Curso Profesional de Backend