@Sb2512 , You can make use of the proxy component pattern to avoid exposing the exact component location within AEM repo while using a resource type bound servlet.
Although, this is not the primary use case of using the proxy component pattern but it does give you this ability as well.
You can refer to the below documentation links to under stand how this works :
Binding servlets by paths has several disadvantages when compared to binding by resource types, namely:
path-bound servlets cannot be access controlled using the default JCR repository ACLs
path-bound servlets can only be registered to a path and not a resource type (i.e. no suffix handling)
if a path-bound servlet is not active, e.g. if the bundle is missing or not started, a POST might result in unexpected results. usually creating a node at /bin/xyz which subsequently overlays the servlets path binding
the mapping is not transparent to a developer looking just at the repository
Given these drawbacks it is strongly recommended to bind servlets to resource types rather than paths.
In the specific case you highlighted we can control the resource bound one with ACLs and can prevent any potential misuse here
@Sb2512 , You can make use of the proxy component pattern to avoid exposing the exact component location within AEM repo while using a resource type bound servlet.
Although, this is not the primary use case of using the proxy component pattern but it does give you this ability as well.
You can refer to the below documentation links to under stand how this works :
If you are building apis that accept different parameters or may be upload some to process before responding back you can comfortably use path based servlet. Sling doesn't discourage path based servlets all together. But suggests usage of resource type based servlets when you intend to perform actions specific to a resource in context as it helps controlling the access based on the resource etc. Follow the links shared in other replies from our community members.
