During the past half month, I have been learning to develop back-end API with ThinkPHP framework of PHP. Now let’s summarize and document what needs to be done to develop an interface that is both efficient and scalable.

I. Process summary

This is basically the process, skipping the environment setup:

  1. Sort out the interfaces
  2. Design data sheet
    • Initial combing is one-to-one, one-to-many, or many-to-many
  3. Writing validators
  4. Writing global exception classes (AOP thinking)
  5. Define routing Paths
  6. Creating a controller class
  7. Building model classes
    • Use ORM, so establish and data table corresponding model class
  8. The controller calls the model, and the model calls the database to complete the interface writing

Ii. Specific instructions

Once you’ve sorted out what the interfaces are, you can start designing the data table:

The data table will be adjusted and changed as the code is written.

Note that when there is a many-to-many relationship between two tables, remember to design an intermediate table to hold the ids of both tables.

Once you’ve designed your data tables, start writing some utility classes to help you be more efficient when writing business code.

The first is the validator.

TP5 framework comes with a validator class, we need to do is to inherit the validator class, and then according to the specific interface to do extension.

Create a validator base class to put common methods in:

The goCheck() method is called by all concrete validators, which simply override the validation rules and return information.

In the goCheck() method, the Request class is instantiated. The purpose of this is to get the parameters passed by the caller when the API is called. Once you get the parameters, it’s natural to validate them. The check() method calls the validation rule function set in each specific validator.

Then there’s the Global exception class.

Similarly, the TP5 framework comes with an exception class, and we create an exception base class to inherit it.

What you then need to do is override the HTTP status code, the error message and error code, for the specific interface.

As for the definition of error code, it is to design a set of specifications.

With the validator and global exception classes set up, we just need to call them in the function of each interface:

Ok, now that we have some basic stuff in place, let’s start writing the interface code.

First define the routing path:

In route.php, introduce the Route class and define the path. Variables in the path are represented by: + variable name. Variables in the path are received by the function specified at the end of the path, which is defined in the corresponding class of the controller.

For example, the id variable:

As shown above, in the controller, when we get the parameters passed by the caller through the routing path, we call the model, pass the parameters, and the model handles the specific database calls.

This is another important point to note, the controller tries to only do the connection, not the concrete operation.

Then, after establishing the controller, it follows that the corresponding model needs to be established.

TP5 also comes with the Model class, and then we define our own Model base class, which is also the Model class of TP5:

Model base classes are also naturally a more general way to define methods. For example, in the example above, a method is defined to return the image prefix link. This method is used to concatenate the image URL for different interfaces but related to the image call.

Now, there’s another caveat here. If you want to create a global variable, you can create an extra directory file in the application directory, and then create setting.php, which returns an associative array:

A subsequent call to the config function, as shown in the prefixImgUrl method in the model base class above, passes in the filename and the key of the associative array.

Returning to the model, each interface will have its own model class, which corresponds to a table, for example:

Since the Banner Model class inherits TP5’s Model class from the Model base class, all we need to do is override some properties to fit the specific interface, such as overriding the $hidden property to define which fields the interface returns that we want to hide.

Then, one of the key points of ORM is to call the model class that the data table corresponds to. For example, in the Items method, hasMany() is used to determine the relationship between the Banner model and BannerItem model. The getBannerById() method then calls the method ORM uses to manipulate the data, which encapsulates the native manipulation database statement, and the ORM returns a model object with attributes and methods that manipulate the data in addition to the database data. This is an advantage of ORM over native SQL statements.

Finally, the controller calls the model’s getBannerById() method, retrieving the data and passing it back to the interface caller as the interface return value. This completes the writing of an interface.

Third, summary

A brief documentation of the back-end API development process has been made. There is a lot of detail left out, just a brief description of a process, but that is not the main purpose of this record. The purpose of this time is to keep a record of this week’s learning.

Through this study of back-end API development, I have consolidated my understanding and application of object-oriented programming ideas.

Through inheritance and rewriting, code can be written cleaner and cleaner.

Classes, instances, properties, methods, how to look at them, and then operate on them, and I learned a lot more about them through this study.