cs3org
application module
The application endpoints are very ownCloud/NextCloud related. A better endpoint would be a capabilities one where clients could check which modules of the spec (shares, federatedsharing, privatedata ..) are enabled or not to behave accordingly.
Is this the objective of the application endpoint?
So the idea is that a server first queries the /ocs-provider/ endpoint which provides the realy API endpoints. This gives different implementation the needed flexibility because of different architectures or technologies.
The application endpoints are very ownCloud/NextCloud related. A better endpoint would be a capabilities one where clients could check which modules of the spec (shares, federatedsharing, privatedata ..) are enabled or not to behave accordingly.
Is this the objective of the application endpoint?
WebDAV e.g. handles this within responses to OPTION requests. Furthermore a simple NotFound to an API endpoint can let the client know that this feature is not enabled.
So the idea is that a server first queries the /ocs-provider/ endpoint which provides the realy API endpoints. This gives different implementation the needed flexibility because of different architectures or technologies.
From my pov this is service discovery which is handled by the well-known RFC - https://tools.ietf.org/html/rfc5785 - no need to invent something new.
Added the wontfix label because it's out of scope.
service discovery should be part of the spec from my pov
Reopened for further discussion, we'll use the Projects feature to determine scope.
