Códigos de estado o HTTP response status codes

Con el decorador  @HttpCode puedes personalizar el status code para tus endpoints 😮

CODIGOS DE ESTADO
Bueno esta parte si eres nuevo , para que entres en contexto te recomiendo la siguiente pagina => https://http.cat/

Nest nos permite utilizar nuestros propios estados , para esto debemos importar nuestro decorador HttpCode y opcionalmente HttpStatus

import {Controller,Post,HttpStatus,HttpCode} from '@nestjs/common';

Y definir el código de estado

 @Post("rute")
  @HttpCode(code)
  create(@Body() payload: any) {
    return {
      message: 'acción de crear',
      payload,
    };
  }

Dije que HttpStatus es opcional ya que podemos definir el código de 2 maneras , numero o por las propiedades de HttpStatus

@HttpCode(HttpStatus.CREATED)

ó

@HttpCode(201)

Aunque personalmente prefiero definirlo por números

Resumen de los códigos HTTP

• Con imágenes de perritos 🐶
• Con imágenes de gatitos 🐱

Para mi no es recomendable usar la forma del decorador para devolver una respuesta. ¿qué pasa si buscas productos y no hay productos? para mi lo lógico seria regresar un 404 y un mensaje de “no se encontró información”. Esto a futuro ayuda muchisimo con las pruebas que se realicen a la API y en el desarrollo del front al interceptar todas las respuestas que se obtengan y manejarlas de forma más fácil.

Informational responses (100–199)
Successful responses (200–299)
Redirects (300–399)
Client errors (400–499)
Server errors (500–599)

Ahi revisando el header del response, veo que por defecto usa express como motor para levantar la aplicacion.

X-Powered-By: Express
Content-Type: application/json; charset=utf-8
Content-Length: 11
ETag: W/"b-BfDWjle+nLCXbOxW3/J6xVZmCOI"
Date: Sun, 16 May 2021 17:25:48 GMT
Connection: keep-alive

Lo veo como un estado esperado, por que en caso de error se tendria que personalizar el tipo de respuesta y codigo diferente al que deberiai.

Utilizando el Res de Express, solo conocimiento

Códigos de respuesta

Como se mencionó, son numerales descriptivos de nuestro aplicativo y dependen de nuestro desarrollo.
.
En NestJS toda operación efectuada tendrá el código de respuesta 200 - OK a menos que sea un método post, el cual tendrá un método de respuesta 201 - Created.
.
📚 NestJS Exception filters
.
En mi experiencia, me ha funcionado desarrollar un controlador que después sea implementado por Express como middleware de error. Así mismo, he podido adecuarlo a los diferentes frameworks para operar.
.

ⴵ Gist de Repositorio GitHub: Zentrity

.

Nota. En aras de continuar con nuestro curso, omitiré la implementación de este controlador en NestJS hasta que sea prudente.

.

// controllers/ErrorServer.controller.ts
/**
 * @class ErrorServer
 * @description ErrorServer collection in server. */
export default class ErrorServer extends Error {
    /**
     * @description Representational error code. */
    public code: number

    /**
     * @description Error message as default. */
    public error: string

    /**
     * @private
     * @description Dictionary of error controller. */
    private readonly errors: { [key: string]: any } = {
        SERVER: {
            code: 500,
            message: 'Internal Server Error',
        },
        DRIVER: {
            code: 503,
            message: 'Service Unavailable',
        },
        BAD_REQUEST: {
            code: 400,
            message: 'Bad Request',
        },
        UNAUTHORIZED: {
            code: 401,
            message: 'Unauthorized',
        },
        NOT_FOUND: {
            code: 404,
            message: 'Not Found',
        },
        EXIST: {
            code: 409,
            message: 'Conflict',
        },
    }

    /**
     * @constructor
     * @param {string} type Error type
     * @param {string} message Error message */
    constructor(type: string, message?: string) {
        super(message || 'without trace')
        this.code = this.errors[type].code
        this.error = this.errors[type].message
    }
}

Información del Curso de Postman de platzi:

1xx: Indican que la peticion fue recibida y el servidor sigue trabajando en el proceso, es decir, no fue exitosa ni fue errónea, sino que esta siendo procesada aun.
2xx: Indican que la peticion fue recibida y procesada correctamente.
3xx: Indican que hay que tomar acciones adicionales para completar la solicitud. Por lo general estos codigos indican redireccion. Generalmente en los APIs no se usan redirecciones porque no contienen estados, es decir, toda la informacion esta contenida en una solicitud, no se guarda un estado en el servidor con una sesion por ejemplo.
4xx: Indican errores del lado del cliente, por ejemplo: se hizo mal la solicitud, faltan datos, headers o cualquier otro error que pueda ocurrir.
5xx: Indican errores del servidor. Suelen aparecer cuando existe un fallo en la ejecución en el servidor.

Hasta ahora se ve buenísimo este framework 😄

muy buenas las clases, creo que es el framework que menos me ha costado comprender… peeeroooo dejemos de aplazar los temas, de aquí para atrás no sé cuántas veces te escuche decir “pero lo veremos más adelante”, y la verdad no me agrada dejar materia a medias…

Me gusto mucho esta seccion. Ya tengo varios anios de experiencia con Express y con los conceptos de una REST API pero el profe explica muy bien y va dando pequenios tips que hacen que valga la pena verlo 😃

Nest utiliza internamente express, y se pueden manipular código directamente de express en nest, pero debería ser utilizado solo en casos bastantes puntuales

HttpStatus y HttpCode

👏

Fastify no tiene tantos tutoriales, pero su documentación es buena y los benchmark son 🔥