The ROUTER Module

The ROUTER module handles mapping of URL routes (e.g. somewebsite.com/api/users/) to various object functions.

When the front-end of a FW App calls the back-end, it calls one specific Php file, no matter what URL it is retrieving data from. The URL it is trying to retrieve is then parsed and then converted into a function call.

Using the standard application layout (client/server folders, etc.), all of the backend api requests go through a file called v1.0.php. What comes after that filename is the "route" that gets "mapped" to a specific function, be it a method in a class or a generically defined function.

For example, if a GET request were made to your-app-url.com/api/v1.0.php/depts/, the "route" section of the url would be /depts/. The router would take that "route" and, depending on how you map your routes, call a specific function. This structure is helpful to know especially when testing network requests directly through an application such as Postman (as documented in this Knowledgebase Entry).

If you want to understand more about how this router structure works in general, you can look at the code. The v1.0.php file can be found in the client/public/api/ folder (if you are in a developing mode app), or just public/api (if you are in production mode). This file should not be changed, as it will impact the routes for the entire app. Since this file essentially initializes api.php in the FW API, which in turn creates an instance of the Loader class, you can find some level of code-generated documentation for it here.

Standard Router Implementation

The standard router implementation uses a library called Slim Framework. URL calls are mapped using the Route Mapper, which then calls the appropriate method on a controller object. The next couple of files explain in more detail each step of the process, and how you as an app developer hook into this process to define your app's routes.