Cleaning the default Laravel application

Building APIs in Laravel

My biggest problem building APIs in Laravel is that it is designed to be a full-stack application framework. This means that everything makes sense when you want a full-stack application. However, that isn't always the case, and it can be pretty frustrating to unpick all of the full-stack parts before even getting started. There are a lot of skeleton projects out there that have already done this or implemented their boilerplate way of setting up and building APIs in Laravel. I will not be using any of these here, though, as I want to walk you through how you should do it and the choices you must make along the way.

At this stage, we need to decide whether to enable a UI element for API key management or go completely "headless" without a UI aspect. Typically this is defined in the scope when you first get around to it - so let us look at the arguments we would typically go through. With a UI, it allows potential admin access and audit control for your API. Without a UI, we would need to build a second application to provide this management level. I am a fan of having the UI there so that I can add management tools etc., all into one application, and it is self-contained. To achieve that, I usually lean on Laravel JetStream and allow the API feature in the configuration. This allows application users to configure and set up multiple API keys to work with the product as needed. You can add additional rules and requirements around this should the need arise.