| ... | @@ -38,15 +38,36 @@ The above endpoint will reject any request from a user not authorized in the Pla | 
... | @@ -38,15 +38,36 @@ The above endpoint will reject any request from a user not authorized in the Pla | 
| 
 | 
 | 
 | 
 | 
| 
 | 
### API Endpoint Routing
 | 
 | 
### API Endpoint Routing
 | 
| 
 | 
 | 
 | 
 | 
| 
 | 
The current API routing scheme is simple, but disorganized, due to all API routes living in the `ModuleConfig` for the `v1` module. For instance, the API endpoint to list all available seasons using the `seasons` handler with the `list` function is:
 | 
 | 
Prior to April 2020, the current API routing scheme was simple but disorganized due to all API routes living in the `ModuleConfig` for the `v1` module. For instance, the API endpoint to list all available seasons using the `seasons` handler with the `list` function is:
 | 
| 
 | 
 | 
 | 
 | 
| 
 | 
`.route( "/seasons/list" )
 | 
 | 
```.route( "/seasons/list" )  
 | 
| 
 | 
   .withAction( {  
 | 
 | 
   .withAction( {  
 | 
| 
 | 
      GET = "list"  
 | 
 | 
      GET = "list"  
 | 
| 
 | 
   } )  
 | 
 | 
   } )  
 | 
| 
 | 
   .toHandler( "seasons" )`  
 | 
 | 
   .toHandler( "seasons" )`  
 | 
 | 
 | 
 | 
```
 | 
| 
 | 
 | 
 | 
 | 
| 
 | 
*TODO*: Look at breaking up API endpoints to the relevant modules, e.g. referee-related API endpoints to the referee module and then using `.toModuleRouting()`
 | 
 | 
Much better is the example of `/vendorIntegration` in which the same routes may be defined, but the definitions live in the relevant module's router and not the API ModuleConfig, e.g.
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
```
 | 
 | 
 | 
 | 
route( '/vendorIntegration' )  
 | 
 | 
 | 
 | 
	.toModuleRouting( 'vendorIntegration' )
 | 
 | 
 | 
 | 
```
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
Which then maps to the vendorIntegration's ModuleConfig.cfc routing:
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
```router  
 | 
 | 
 | 
 | 
     .route( "/" )  
 | 
 | 
 | 
 | 
	.to( "Home.index" )  
 | 
 | 
 | 
 | 
     .route( "/certifications" )  
 | 
 | 
 | 
 | 
	.toHandler( "vendorCertificationsAPI" )  
 | 
 | 
 | 
 | 
     .route( "/home/:action" )  
 | 
 | 
 | 
 | 
	.toHandler( "Home" );`
 | 
 | 
 | 
 | 
```
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
This module's routing has a traditional Coldbox handler of `Home` handling regular requests, and an API handler of `vendorCertificationsAPI`, such that the following endpoint will route to it:
 | 
 | 
 | 
 | 
 | 
 | 
 | 
 | 
`https://api.inleague.io/v1/vendorIntegration/certifications`
 | 
| 
 | 
 | 
 | 
 | 
| 
 | 
### API Endpoint Caching
 | 
 | 
### API Endpoint Caching
 | 
| 
 | 
 | 
 | 
 | 
| ... | @@ -54,9 +75,9 @@ The current API routing scheme is simple, but disorganized, due to all API route | 
... | @@ -54,9 +75,9 @@ The current API routing scheme is simple, but disorganized, due to all API route | 
| 
 | 
 | 
 | 
 | 
| 
 | 
1. **Event function definition**: Specify `cache=true` and `cacheTimeout=someNumber` in the event, e.g.
 | 
 | 
1. **Event function definition**: Specify `cache=true` and `cacheTimeout=someNumber` in the event, e.g.
 | 
| 
 | 
 | 
 | 
 | 
| 
 | 
`public function lookupUser( event, rc, prc, string username ) cache=true cacheTimeout=10 {`
 | 
 | 
`private function lookupUser( event, rc, prc, string username ) cache=true cacheTimeout=10 {`
 | 
| 
 | 
 | 
 | 
 | 
| 
 | 
2. **runEvent()**: When calling a Coldbox event internally, you can specify (or override) cache values using the `cache` and `cacheTimeout` arguments.
 | 
 | 
2. **runEvent()**: When calling a Coldbox event internally, you can specify (or override) cache values using the `cache` and `cacheTimeout` arguments. You must also specify `prePostExempt=true` so that it does not try to execute the aroundHandler, which would fail on a private function.
 | 
| 
 | 
 | 
 | 
 | 
| 
 | 
There are two considerations to keep in mind when using event caching:
 | 
 | 
There are two considerations to keep in mind when using event caching:
 | 
| 
 | 
 | 
 | 
 | 
| ... |  | 
... |  | 
| ... |  | ... |  |