Laravel API: Be Careful When Doing Changes

In this video, I apologize for the non-ideal advice that I gave a few videos ago. Let's talk about "sensitive" changes in your Laravel API.

- - - - -
Support the channel by checking out our products:

[ndeblauw]

Often the second thought is aligned with the first thought and concerns details that are worth fixing (when programming) but not shooting a new video. It's great to see that you dare to share your second thought/insight when the difference matters!

[randomguy]

I really like your channel, because you not only teach us, but you deal with real problems and also try to update you along with the code.
Thanks a lot dr.

[susananzth]

Trabaje desde Perú en conjunto con un equipo de desarrollo en USA y otro de la India. Y a pesar que eran equipos de desarrollo con "más experiencia" en desarrollo de API que ni equipo, siempre nos retrasaba cuando realizaban cambios en el request o response de las apis. Y la app quedaba inutilizada por 2 o 3 días hasta que Google aceptará la nueva versión. Y el equipo de USA o INDIA solo respondía "que pena" y seguía incurriendo en la falta. Es muy frustrante esto. 🤬😡

Admiro que haya hecho este video 🤗
A muchos desarrolladores les falta unas toneladas de auto reconocimiento de cagadas.

[rossco]

Storm in a teacup! I found the tips on how to better respond very useful in the original video, and I thought it was implicit that the frontend would adjust accordingly. It's a valid point that you need to consider the frontend, but that point shouldn't get in the way of coaching for best practice like you were doing. Play on!

[mohamedshuaau]

I’m glad I hot here. I’ve seen very few developers apologizing for their own mistakes. Of course everyone makes mistakes or gives wrong advice (intentionally or not). Thank you for the content!

[paulfontaine]

That is why some people stick to 'if it ain't broken, don't fix it'. Make good choices during development instead, and the reason why Povilas made the error was because he wanted to teach us what to do during development.

[bboydarknesz]

Yes, the point here is the output.
Don't change it too much if it already used by someone.
Especially in mobile, as mobile dev I cry with my Backend Developer always make change the output and make old mobile version crash 😢 😢 😢
Better have version in api

[ward]

The more I write JSON APIs with Laravel, the more I am inclined towards having some wrapper around any type of response. Saves from visual debt + gives consistency.

[MrStealthWarrior]

Had to implement new version of API because of mobiles when changes were made to my code.
Would like to see a video on how to make new versions of API when you have small/significant/breaking changes in your code.

[ootommo]

Would you be able to make a whole run through video or checklist explaining all the available features of Laravel, eg gates, custom request classes etc. Or even just the main components that would typically be brought together in a Laravel 8 build. ♥️

[bagusSetyawan]

I think depend on team, every team has their own design, my team using status rsponse custom code to indicate the status so http code always 200, the other http code will work what is their default. Its good to split network status and response status

[bumblebity]

1:32, why you still using status code 500, although it is authorization error, not the server one.

[sntlln]

5:10 yes! Recently i made a similar mistake 😅

[Raftor]

It is never worth returning 500 status if there is any problem with user input. To do this, it is better to use the following statuses: 400 Bad Request, 409 Conflict, 403 Forbidden