When we start developing web applications, one of the first things we need to learn is how to define application routes. A route determines which code will be executed when someone accesses a specific URL.
For example, imagine you are developing an application and need to provide the following URLs:
-
/– Home page. -
/users– List of users. -
/products– List of products. -
/login– Authentication page.
Normally, we would need to register each of these routes manually. However, Inphinit provides a feature called Implicit Routes, which simplifies this process.
With this feature, we can define routes directly inside a class's methods using naming conventions. This means Inphinit automatically identifies the HTTP method and route path based on the method name.
In this article, we will explore this feature and learn how to use it through simple and practical examples.
1. Creating our first controller
Before getting started, we need to create a class responsible for storing the methods that will be executed by our routes.
In Inphinit, we can use the Inphinit\Routing\Treaty class as the base class for our controller.
Let's create the following file:
system/Controllers/ImplicitController.php
Then add this code:
<?php
namespace Controller;
class ImplicitController extends \Inphinit\Routing\Treaty
{
public function getIndex()
{
return 'My first application with Inphinit!';
}
public function getAbout()
{
return 'This is the about page.';
}
}
Notice that we created two methods: getIndex() and getAbout().
But how does Inphinit know which URL each method represents?
That's where implicit routes come in!
To make Inphinit recognize these methods, we need to register our controller in the application's main file, such as main.php or dev.php:
\Controller\ImplicitController::action($app);
From this point on, Inphinit identifies the compatible methods and automatically registers their corresponding routes.
In this example, we will have:
| URL | HTTP Method | Response |
|---|---|---|
/ |
GET | My first application with Inphinit! |
/about |
GET | This is the about page. |
Notice that we don't need to declare each URL individually. The method names already provide the necessary information.
2. Understanding HTTP prefixes
The first part of the method name indicates which HTTP method will be used.
An HTTP method defines the type of operation we want to perform on the server.
The most common prefixes are:
-
get: Used to retrieve or query information. -
post: Used to send data to the server, usually to create records. -
put: Used to update a resource. -
delete: Used to remove a resource. -
head: Similar to GET, but returns only the response headers. -
any: Allows the same controller method to handle different HTTP methods.
Let's understand each one through examples.
2.1. GET – Retrieving information
The get prefix is used when we want to provide a route for retrieving information.
Imagine we are developing an application that contains a list of products.
We can create the following method:
public function getProducts()
{
return 'Product list';
}
Inphinit will automatically recognize the following route:
GET /products
When someone accesses this URL using a GET request, the getProducts() method will be executed.
Another example would be retrieving product details:
public function getProduct()
{
return 'Product details';
}
In this case, we will have the following route:
GET /product
The important thing to remember is that the get prefix identifies the HTTP method, while the remaining part of the method name defines the route path.
2.2. POST – Sending information
The post prefix is used when we need to receive information submitted by the client.
A common example is user registration.
Imagine we have a form containing name and email fields. When the user submits this form, the data can be received through a POST route.
public function postUsers()
{
$name = $_POST['name'] ?? '';
$email = $_POST['email'] ?? '';
return "User {$name} registered!";
}
The generated route will be:
POST /users
In this example, we use $_POST to access the data submitted through the form.
In a real application, we would also need to validate the information and store it in a database.
2.3. PUT – Updating information
The put prefix is used when we want to update an existing resource.
For example, imagine that our application allows users to update product information.
public function putProducts()
{
return 'Product successfully updated!';
}
The generated URL will be:
PUT /products
When a PUT request is sent to this URL, the corresponding method will be executed.
This type of route is commonly used in REST APIs for update operations.
2.4. DELETE – Removing information
The delete prefix is used when we need to remove a resource.
Imagine we want to provide an operation for deleting a product:
public function deleteProducts()
{
return 'Product successfully deleted!';
}
The generated route will be:
DELETE /products
When the client sends a DELETE request to /products, Inphinit will execute the deleteProducts() method.
In a real application, we would normally also receive an identifier to determine which product should be deleted.
2.5. ANY – Accepting different HTTP methods
In some situations, we may want a route to accept different HTTP methods without creating a separate method for each one.
For this purpose, we can use the any prefix.
Consider the following example:
public function anyStatus()
{
return 'Application is running!';
}
The generated route will be:
ANY /status
This means the method can handle requests using different HTTP methods.
This feature can be useful in certain situations, but it should be used carefully. When an operation has a specific purpose, such as creating or deleting information, it is preferable to use the corresponding HTTP method.
3. Creating routes with compound names
So far, we have used simple method names, such as getProducts() and postUsers().
But what if we need to create URLs containing more than one word?
Inphinit also supports this!
Simply follow the method naming convention. When a new word begins with an uppercase letter, it is converted into a separate part of the URL, with words separated by hyphens.
For example:
public function getAboutUs()
{
return 'Learn more about our company.';
}
public function getProductList()
{
return 'Here are our products.';
}
public function postSendMessage()
{
return 'Message sent!';
}
The corresponding routes will be:
| Method | Route |
|---|---|
getAboutUs() |
GET /about-us |
getProductList() |
GET /product-list |
postSendMessage() |
POST /send-message |
This convention makes it easier to create readable and well-organized URLs without manually writing each route path.
4. Understanding the Index method
Another interesting detail about implicit routes is the use of the Index name.
When we use Index after the HTTP prefix, we indicate the main route, represented by the / path.
Consider the following example:
public function getIndex()
{
return 'Home page';
}
The generated URL will be:
GET /
We can also use this convention with other HTTP methods:
public function postIndex()
{
return 'Data received at the root route!';
}
In this case, we will have:
POST /
This can be useful when we want to provide different operations using the application's root URL.
5. Practical example: creating a simple users controller
Now that we understand the main prefixes and naming conventions, let's put everything together in an example that is closer to a real application.
Imagine we are developing a simple API for managing users.
Our controller could look like this:
<?php
namespace Controller;
class UsersController extends \Inphinit\Routing\Treaty
{
// Displays the API home page
public function getIndex()
{
return 'Users API';
}
// Lists users
public function getList()
{
return 'User list';
}
// Displays user details
public function getDetails()
{
return 'User details';
}
// Registers a user
public function postRegister()
{
return 'User registered!';
}
// Updates user information
public function putUpdate()
{
return 'User updated!';
}
// Removes a user
public function deleteRemove()
{
return 'User removed!';
}
}
To register this controller, we use:
\Controller\UsersController::action($app);
This gives us the following routes:
| HTTP Method | URL | Purpose |
|---|---|---|
| GET | / |
Displays the API |
| GET | /list |
Lists users |
| GET | /details |
Retrieves user details |
| POST | /register |
Registers a user |
| PUT | /update |
Updates a user |
| DELETE | /remove |
Removes a user |
Notice how we can organize several operations inside a single class, making the application's structure easier to understand.
Of course, this example uses illustrative responses. In a real application, these methods would be responsible for retrieving, inserting, updating, and deleting database records.
6. Implicit or explicit routes: which one should you use?
Inphinit also supports explicit routes, where we manually declare the HTTP method, URL, and handler responsible for processing the request.
For example:
$app->action('GET', '/users', 'UsersController::list');
$app->action('POST', '/users', 'UsersController::register');
With this approach, we have direct control over each route mapping.
With implicit routes, we can achieve a similar result by following the method naming convention:
public function getUsers()
{
return 'User list';
}
public function postUsers()
{
return 'User registration';
}
An important difference is that explicit routes allow multiple HTTP methods to be associated with the same handler, whereas implicit routes use a separate method for each HTTP prefix.
Therefore, we can choose the approach according to the project's requirements:
- Implicit routes: Useful for applications that follow naming conventions and need a more concise configuration.
- Explicit routes: Useful when we need greater control over URL mappings and handler sharing.
Conclusion
Implicit routes are an interesting Inphinit feature for developers who want to build PHP applications with an organized structure and fewer repetitive configurations.
Their main advantage is simplicity: instead of manually registering each route, we can use method names to tell the framework which URL and HTTP method should be used.
By understanding the get, post, put, delete, head, and any prefixes, as well as compound naming conventions and the use of Index, we already have a solid foundation for getting started with this feature.
The most important thing to understand is that implicit routes do not eliminate the need to plan an application's endpoints. They simply make the process of defining and organizing those routes more practical.
Top comments (0)