I think currently POST is handled the same way as GET. That’s a historical thing where there was only one function for the API – to serve data. We were also quite unskilled at the time. So GET or POST did not matter.
It could be corrected with some backwards compatibility switch. We could also rename “Pages” to “API” in the metamodel.
Along this, the current metamodel has a limitation, as @vikter noted when discussing it. The PUT and DELETE APIs cannot be controlled separately by the application roles. So maybe we could invent even better way how to do this: by introducing a child model element to the API – Verb/role association.
Example:
XsltDataPage:
Name: "/api/private/users"
VerbRoleMappings:
- VerbRoleMapping:
Name: "GET"
Verb: GET
Function: RetrieveData
Roles: "*"
- VerbRoleMapping:
Name: "POST"
Verb: POST
Function: CreateRecord
Roles: "CreateNewUser"
The backwards compatibility would then go like this:
- VerbRoleMapping:
Name: "POST"
Verb: POST
Function: RetrieveData
Roles: "*"
So RetrieveData function would be assigned to the POST verb.
OTOH now as I am reiterating on this, we can already control who can create/delete data by having row-level-security rules in place. But anyway, such metamodel update would make the API design simple and more transparent.
