The API controllers all extend from the core
\Joomla\CMS\MVC\Controller\ApiController
class.
The API controllers will, by default, implement CRUD (Create, Read,
Update, Delete). Do note that Read in this context means both
returning a single item and returning a list of
items.
At a minimum, you need to override the $contentType and $default_view properties.
The $contentType property is used as the
context to the onGetApiAttributes
and
onGetApiRelation
events. The former is used to
modify the data of the JSON response. The latter is used to add
related data to the JSON response.
![]() | Note |
---|---|
Unfortunately, the content type is a very bad
choice for context in these events because it's not
unique across components and the component's name is not given in
the event arguments. For example, the type For this reason, you may want to provide your extension's
$contentType in the format
|
In most cases you do not want to change the
displayItem
(read one),
displayList
(read many),
delete
(remove), add
(create), and edit
(update) methods. When you
do, it's mostly so you can set a filter state in the view's Model.
Joomla's core components do that a lot in their api application
part.
You will most likely need to override one or more of the following methods for most real world components:
-
allowEdit
. Is the current user allowed to edit (update) the item? By default, it only checks thecore.edit
privilege of the current user for your component. The method is passed the data and the table's primary key in case you need to do more fine grained access control. For example, a forum component will very reasonably only allow the user who posted a specific post and the forum administrators to edit a post, not any random person who can post into the forum. -
allowAdd
. Is the current user allowed to add (create) a new item? By default, it only checks if the currently logged in user has thecore.create
privilege for your component or they have thecore.create
privilege in any categories which belong to your component (assuming you are integrating with Joomla's com_categories). The method is passed the data to be created in case you need to perform more fine-grained access control. For example, a helpdesk component would only allow the user who owns a support ticket and the support staff to post replies to a specific ticket. The view handling replies would check the ticket ID in the data to determine if this is the case before allowing a new post to be created. -
preprocessSaveData
. This is executed after allowEdit and allowAdd, but before handling tags and saving the data into the database. This is your last chance to make any modifications to the data before committing it to the database. For example, you may want to perform additional validation and cleanup of HTML content, or you may want to automatically fill in missing information which would cause a validation error when the Model tries to save the data.