You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
All the the resources contain strings which create the endpoint URLs to send to Mauro, but there is a lot of duplication. For example, a lot of resources contains some standard CRUD based endpoints - get, list, update, remove` etc - though their endpoints only differ by their domain type.
Maintaining all these endpoints becomes more cumbersome, especially when related endpoints need to be updated but some do not have the same types/parameters assigned for consistency.
Base Classes and Endpoints
A recent set of work - MC-9840, MC-9841 and [MC-9889](https://metadatacatalogue.myjetbrains.com/youtrack/issue/MC-9889] - tried to help with this by designing some interfaces and base classes to encapsulate/inherit from common operations - e.g. CRUD, branch/version/forking, export/import etc. These can then be applied to multiple domains so the domain based, derived resource classes don't have to duplicate the same operations.
This idea could be extended to all the other resources, so:
They derived from a suitable base class
Remove the duplicate endpoints inherited, but keep the domain-specific endpoints
Also, applying interfaces to the resource classes will allow a client to refer to multiple domain types that can perform the same action, eg.
constexportResource: ExportableResource=getExportResource('dataModels')// or any domain typeexportResource.exporters();// fetch exporters for this chosen domain type
Rationalisation of types
A lot of type definitions have also been created to add assistance for understanding the payloads of endpoints and their possible response types, but these could also be rationalised and streamlined. Particular use case is understanding the domain type names, since:
Some must be plural camelCase,
Some must be singular PascalCase,
Some domains are only relevant for certain endpoints
etc
The text was updated successfully, but these errors were encountered:
Rationale
All the the resources contain strings which create the endpoint URLs to send to Mauro, but there is a lot of duplication. For example, a lot of resources contains some standard CRUD based endpoints -
get
,list
,update,
remove` etc - though their endpoints only differ by their domain type.Maintaining all these endpoints becomes more cumbersome, especially when related endpoints need to be updated but some do not have the same types/parameters assigned for consistency.
Base Classes and Endpoints
A recent set of work - MC-9840, MC-9841 and [MC-9889](https://metadatacatalogue.myjetbrains.com/youtrack/issue/MC-9889] - tried to help with this by designing some interfaces and base classes to encapsulate/inherit from common operations - e.g. CRUD, branch/version/forking, export/import etc. These can then be applied to multiple domains so the domain based, derived resource classes don't have to duplicate the same operations.
This idea could be extended to all the other resources, so:
Also, applying interfaces to the resource classes will allow a client to refer to multiple domain types that can perform the same action, eg.
Rationalisation of types
A lot of type definitions have also been created to add assistance for understanding the payloads of endpoints and their possible response types, but these could also be rationalised and streamlined. Particular use case is understanding the domain type names, since:
The text was updated successfully, but these errors were encountered: