Why or when to use Laravel resources/collections

There are a couple of primary reasons to use resources to manage your return values even if your resources don't do anything than pass data through today, you may want it to do something different in the future.

A small list of reasons why resources are really useful

1. Data manipulation, specific to clients (i.e. js applications consuming your api)

If you start manipulating data in your models using mutators (getters / setters). Your internal application now has to work with these constraints. Many times its easier to work with the raw data internally and then just allow your resources to manipulate the data for the client.

2. Conforming to an API specification, such as JSON API v1.0

Whilst you will likely need logic in your application to handle schemas like this, your models and controllers should not. The resource has a critical role here to organise the data for your consumer applications in a compliant fashion.

3. The age old mantra, separation of concerns

This goes hand in hand with point 1, it is not a model or a controllers responsibility to map data to what you expect your consumer applications to receive.

Building on your example

You currently have the following in the show route of your resource controller.

public function show(School $school)
{
    // return response()->json($school, 200);
    return new SchoolResource($school);
}

This need not change, even if your API specification does (reason 1 and 3).

Adding fields, yes, you'll need to add them to your model but lets use this to actually do something meaningful with your resource.

We've created a migration for a new JSON field ratings. Ratings has a data structure like this:

[
    {
        name: string,
        value: float,
    }
]

For reasons such as media scrutiny, we never want to expose all the rating data to our publically available front end consumer apps. Instead we want to provide an average score of all ratings.

Now we could do this in the model, but is it the models responsibility to do this? Not really, the model should be handling and dealing in raw / discreetly modified data only. So is it the controllers responsibility? No, the controller coordinates what should be done and is not interested in specific details or the data.

So where do we do this? Enter your resource that was handily already set up.

class School extends JsonResource
{
    public function toArray($request)
    {
        return [
            'id' => $this->id,
            'name' => $this->name,
            'rating' => $this->getRating(),
        ];
    }

    /**
     * Mean rating rounded to one decimal place
     * @return float
     */
    protected function getRating() 
    {
        return (round(array_reduce($this->ratings, function($acc, $curr) {
            $acc += $curr['value'];
            return $acc;
        }, 0) / count($this->ratings), 1);
    }
}

The resource is where we have manipulated data specifically for our responses and left our internal data modelling un-touched and clean without pollution from specific nuances of our consuming applications.

More importantly, if you just returned return response()->json($school, 200); from your controller, your data structures will not match and you would be exposing some sensitive data to your front end applications.

Additional (24/12/21)

It's worth noting that if, for example, the data that you are manipulating is required by many different views / resources then we have a number of options.

1. Traits, create a trait that adds the getRating method. Downside, every class that needs this must import and declare the trait. Upside, your code is dry.
2. Model scopes, add a scope to your model that does the data processing via SQL (or your DB QL of choice). Downside, slight pollution of the model. Upside, super quick.
3. Append the data to the model (https://laravel.com/docs/8.x/eloquent-serialization#appending-values-to-json) using an accessor that runs the getRating code to set the data on the model. Upside, clean and usable throughout the application. Downsides pollutes the model a little and data only available in the JSON representation of the model.
4. Decorate the resource. This allows you to intercept and modify/add to the result of the toArray method in the decorated resource. Upsides not many. Downsides, obfuscated and confusing implementation detail. I wouldn't recommend this approach.
5. Helper function. Rather than have the method on the resource, create a helper that takes the ratings array and returns the result. Upside, simple implementation. Downsides, none that I can thing of.

So after thinking about this alot I think that I would likely do what I originally wrote in this answer. If I need to re-use I would likely create a helper. If I was concerned about performance I would use a model scope to do the calculations in SQL (if possible, remember it's a JSON field). Taking a step further, if many models require this logic, a trait for those models would be my next step (this only applies if you go down the SQL calculation route).