NII Consultation with COS regarding the development direction for API handling #50
Description
https://discordapp.com/channels/1021799209160163389/1021799210393292836/1401730316883726428
Problem Description
Currently, when a request is made to
/v2/nodes/{id}/files/azureblobstorage/
and reaches the OSF api service, the method BaseFileNode.resolve_class() fails to resolve the addon introduced in Gravyvalet.
This is because the legacy implementation of resolve_class() is designed to handle only addons that are implemented within the api service itself. It requires a corresponding BaseFileNode subclass to exist in the api service for each supported provider. Since no such subclass exists for the newly added addon in Gravyvalet, the api service is unable to correctly redirect the request.
Architectural Problem
The core issue is that api service tries to resolve and handle the addon, even though the addon only exists in Gravyvalet, not in the api service. This tightly couples the api service to addon implementations that ideally should be handled elsewhere.
Questions for Architectural Direction
I would like to confirm which of the following directions is considered correct for evolving the architecture:
Change Waterbutler’s authentication flow so that it can directly fetch credentials from Gravyvalet, removing the dependency on OSF/Web/Api to resolve the addon.
Modify OSF/Web/Api so that requests for the new addon can be correctly forwarded to Gravyvalet, even though the web/api service does not have a BaseFileNode subclass for it.