Servicing an API and Web UI from same Laravel installation

@jlrdw thank you for the advice...

In this case, we need an API - or to be more precise, the students have to create an API as part of their assessable items.

We combine this with their Mobile App development so they consume the API when they implement the native app for mobile devices.

@martinbean thank you for the explanation.

The joy of being an educator (primarily) is that I often don't get to spend enough time developing code, so your explanation helps a great deal.

I'm used to doing the web front end + back end combined, but this need for API as well had myself, and my colleague debating best practice.

From my understanding, we put the majority of the logic in the model, returning results to both the API and WEB controllers that then handle how the data is then presented to their respective destinations.

This makes the models 'heavy' and the controllers 'light'.

The controllers could then handle the respective methods to validate requests etc.

With this in mind, creating controllers with names such as ProductsApiController and ProductsController would allow the two to be separate but relatively easy to maintain.

As for the API changes, we are attempting to have the students (and ourselves) understand how to implement APIs, so we are in a luxury situation that changes to the API are not going to affect the clients at this point and the students are very much in charge of both ends of the API loop.

Once again thanks.

From my understanding, we put the majority of the logic in the model, returning results to both the API and WEB controllers that then handle how the data is then presented to their respective destinations.

@ady_gould Yeah, pretty much. If you can keep as much logic in models and services classes, then your controllers end up being “marshals” that take a HTTP request, call the relevant domain logic, and then present the results (whether that be in a Blade template or as a JSON/XML response or whatever).

So if you have an API endpoint to create a post, as well as the ability to create a post from the “web” front-end, then the respective controllers could call on the same service method to accomplish that:

namespace App\Http\Controllers;

class PostController extends Controller
{
    protected $postService;

    public function __construct(PostService $postService)
    {
        $this->postService = $postService;
    }

    public function store(StoreArticleRequest $request)
    {
        $post = $this->postService->create($request->validated());

        return redirect('/posts')->with('success', 'Post was created.');
    }
}

namespace App\Http\Controllers\Api;

class PostController extends Controller
{
    protected $postService;

    public function __construct(PostService $postService)
    {
        $this->postService = $postService;
    }

    public function store(StoreArticleRequest $request)
    {
        $post = $this->postService->create($request->validated());

        return new JsonResponse($post, 201);
    }
}

So both controllers call on the same class and method to create a post, but return different responses depending on if it’s the “web” controller or the API controller. This means that if you need to change how a post is created, you only need to do that in one place (the PostService class).

With this in mind, creating controllers with names such as ProductsApiController and ProductsController would allow the two to be separate but relatively easy to maintain.

I tend to namespace controllers. So above you’ll see I put the API controller in its own sub-namespace (App\Http\Controllers\Api) so that API controllers are separated from the “web” controllers. I’ll do the same for controllers for things like admin panels or whatnot. But this is just personally preference.

@martinbean, Huge thank you!

Your explanations have been great! I do agree that using 'namespacing' is the better option.

I'm going to ask one more question based on your examples: The PostService contains what would be the traditional controller components... minus the response methods...

I found this article: https://blackdeerdev.com/laravel-services-pattern/ which matches that idea.

@ady_gould No problem. Glad I was able to help :)

Yeah, that blog post has pretty much an example of what I was trying to get across. Basically just extracting the business logic from your controller actions, to another class that can then be re-used in multiple places.

Cheers @martinbean

Many thanks again, you've been superb in your explanations and taking the time to step through the process.

I'm giving you multiple 👍