No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Curso de API REST con Laravel

Curso de API REST con Laravel

Profesor Italo Morales F

Profesor Italo Morales F

Versión 2: planificación y configuración inicial

11/18
Recursos

Aportes 7

Preguntas 1

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Siempre versiona tu API. El versionado te ayuda a iterar más rápido y evitar peticiones inválidas desde endpoints actualizados. Además te ayuda a resolver cualquier transición importante de versión de la API mientras continúas ofreciendo viejas versiones de la API por un período de tiempo.

Hay opiniones cruzadas respecto si la versión de la API debería ser incluida en la URL o en el encabezado. Académicamente hablando, debería probablemente estar en el encabezado. Sin embargo, la versión necesita estar en la URL para asegurar la posibilidad de explorar en el navegador los recursos a través de las versiones (recuerda los requerimientos de la API especificados al inicio del artículo).

Soy un gran fanático del alcance que Stripe ha tomado respecto al versionado de la API - la URL tiene un número de versión principal (v1), pero la API tiene las sub-versiones basadas en fechas que pueden ser elegidas mediante un encabezado de petición HTTP personalizado. En este caso, la versión principal proporciona la estabilidad estructural de la API en su conjunto, mientras que las sub-versiones representan cambios más pequeños (campos inhabilitados, cambios en el endpoint, etc).

Una API nunca va a ser completamente estable. El cambio es inevitable. Lo importante es cómo se gestiona el cambio. Anuncios de fechas y planificaciones bien documentados puede ser una buena práctica para muchas APIs. Todo se reduce a lo que es razonable teniendo en cuenta la industria y los posibles consumidores de la API.

fuente: https://elbauldelprogramador.com/buenas-practicas-para-el-diseno-de-una-api-restful-pragmatica/

De hecho una buena práctica al crear nuevas versiones es informar sobre dicha versión en la documentación. Algo que suelen hacer muchas API’s es ponerte en la documentación un mensaje en grande y rojo que dice: “ESTAS USANDO UNA VERSIÓN VIEJA, POR FAVOR CAMBIE A LA V2 DEL API” y es así en donde sabes que debes actualizarte 😄

Me parece que para evitar conflictos con los nombres de los controladores y además ser mucho más organizados, es mejor separar los archivos de rutas.

Así como se registra routes/api.php, podría registrarse routes/api/v1.php y routes/api/v2.php

Estas rutas se pueden registrar en el RouteServiceProvider.

italo que buena organizacion al momento de versionar

Excelente clase, tengo una pregunta, ¿si solo tengo cambios menores en la primera version del api, es necesario crear una nueva version para esas nuevas modificaciones o solo me quedo en la version 1?

en el archivo de ruta al guardar el controlador con otro nombre , al escribir php artisan route:list me dice que no reconoce la clase postv2, que puede ser, gracias?

No sería mejor tener una API que pueda actualizar a los clientes de forma automática?