| ... | ... | @@ -38,6 +38,7 @@ All API endpoints are Coldbox events in handlers extending **BaseHandler**. Each |
|
|
|
6. [Validation](#validating-api-requests)
|
|
|
|
7. [Function](#api-endpoint-function)
|
|
|
|
8. [Conventions (Expand)](#api-endpoint-conventions)
|
|
|
|
9. [Conventions (Pagination)](#api-result-pagination)
|
|
|
|
|
|
|
|
### API Endpoint Authentication
|
|
|
|
|
| ... | ... | @@ -217,3 +218,7 @@ The request object contains commonly-used fields for the logged-in user to reduc |
|
|
|
## Retrieving the User Object for a Request
|
|
|
|
|
|
|
|
In the event that the `qUser` object is needed at any point in the request on the back end, load it with the `getUser()` function on the security object so that it will be cached in that object and remain available for the duration of the request.
|
|
|
|
|
|
|
|
## API Result Pagination
|
|
|
|
|
|
|
|
The inLeague API Response object was originally based on Coldbox 5's HMVC template. We have back-ported the addition of the pagination struct in CB6. The handler must have `prc.pagination` enabled ((`true`)), and then any data-execution functions must use Quick or QB's `.paginate()` functions, and `setDataWithPagination()` on the Response object instead of `setData()`. See this commit for an example in `invoice.cfc`: https://gitlab.inleague.io/inLeague/inLeague/-/commit/d8557f871fa3ac6cefdb3fa01b3d36976d1c0b23 |
