Skip to content

Generator Stubs

Jump to bottom
Max edited this page Jul 25, 2019 · 3 revisions

Generators

Some generators were changed in this boilerplate, to facilitate the API functionality that has been added.

In most cases, the easiest thing to do is just to run the make:api-resource generator - which calls multiple generators, automatically orchestrating the creating of multiple types of infrastructure.

./artisan make:api-resource Book

Here is a list of modified generators, and what has been added;

controller.plain (make:api-resource, make:controller)

This has been re-written to extend the BaseController (or BaseChildController) in the App namespace, and has two things defined by default

  • $model - Every controller will generally be associated with one model, and this should always be defined in the controller as per generated example.
  • $parentModel - If you are using the child restful controller, then this defines the parent model of the main model associated with this controller. If you are not using the child restful controller, then this should be removed or left as null.
  • $transformer - If the controller wishes to impose a transformer that is different from the base transformer, and model transformer, this can be done by defining it here. Most controllers should not need this, and it can be removed if not used.

If you wish to override any of the restful route functions, then you can do so in your controller or in the base controller in your App\Http\Controllers namespace. Have a look at the restful controller implementations to get started.

model (make:api-resource, make:model)

The restful model is a key component of the API boilerplate. A model directly represents a given resource type in the system. Let's take a look at the things you should be aware of;

Properties

Here are properties which are used by the API boilerplate;

  • $primaryKey - This should be a UUID, unique for every instance of the model
  • $immutableAttributes - These are attributes to explicitly not allow to be updated using the API
  • $itemWith - Acts like a $with for eager loading, however only in circumstances where this model is retrieved through the API controllers. It will not act like a $with when this model is used elsewhere internally within the codebase (for example, in services). This is very useful if you don't want the performance issues of eager loading throughout the internals of your application, but do want certain relations always loaded when your API consumers are requesting this resource.
  • $collectionWith - Like itemWith, but only for getAll (GET /) requests. Useful if you want to load less relations on a get all collection endpoint, for performance reasons. By default this is null, which causes $itemWith to be used for getAll().
  • $transformer - If you wish to define a custom transformer to use for this model, specify it here. This will take precedence over the default transformer. If you are not doing this, you can remove this property.

Methods

Here are methods which are used by the API boilerplate. Note that the stub for model does not include all of them, because generally some are infrequently necessary - but you can add them as required.

  • getValidationRules() - Returns an array of validation rules to be used for validating instances of this model, when it is being created through the API. Additionally, a subset of these rules will automatically be used for any relevant fields that are being updated through an API call.

  • getValidationRulesUpdating() - Returns an array of validation rules to be used for updating a model. In most cases, these will be the same as when creating a model - but sometimes you may need to tweak some rules. By default, this returns the output of getValidationRules().

  • getValidationMessages() - Returns an array of custom validation messages, if you wish to define them. Standard laravel validation rule naming applies.

seeder (make:api-resource, make:seeder)

Although not modified for use specifically for an API project, there are some conveniences added. Every seed will have a $faker class property which can be used readily.

The definition of base seeder is in your application's database/BaseSeeder.php file - and you can change this as necessary (for instance, specify a default locale to use for Faker).

Each stub will contain 3 functions. If you are not using any, you can remove them;

  • runFake() - Runs only in when App environment is not production
  • runProduction() - Runs only when App environment is production
  • runAlways() - Runs always, regardless of environment

Table of Contents

Clone this wiki locally