there is an abstract Resource class with multiple non-abstract methods defined
all particular resources inherit from this Resource class
some methods for some resources don't work
(I understand this is against some of the the object oriented programming principles, nevertheless I think this is a correct design, at least at this stage of the development).
Example: we can now call await activity.get_data() and get a traceback, because Activity doesn't have any direct GET.
Anyway, there are few directions from here:
A direct fix. Split Resource to subclasses and change the inheritance tree so that every class has only correct methods.
Try to fill the gaps.
In yagna. For example, I would totally love to have an option to find the agreement_id for a particular activity_id and this could be done via activity.get_data(). UPDATE: there is now /activity/activity_id/agreement endpoint.
Using current endpoints. E.g. GET /activity/activity_id/usage could be available under activity.get_data(). I'm not saying this is good, only that it's worth considering.
In general, I think that "Activity is the only special resource without get_data method, but instead has some other methods that return activity data" is not a great API design. IOW: current capabilities of the yagna API should not define golem_api interface.
--> This requires some thinking.
The problem is pretty clear:
Resourceclass with multiple non-abstract methods definedResourceclass(I understand this is against some of the the object oriented programming principles, nevertheless I think this is a correct design, at least at this stage of the development).
Example: we can now call
await activity.get_data()and get a traceback, because Activity doesn't have any direct GET.Anyway, there are few directions from here:
Resourceto subclasses and change the inheritance tree so that every class has only correct methods.yagna. For example, I would totally love to have an option to find theagreement_idfor a particularactivity_idand this could be done viaactivity.get_data(). UPDATE: there is now/activity/activity_id/agreementendpoint.GET /activity/activity_id/usagecould be available underactivity.get_data(). I'm not saying this is good, only that it's worth considering.In general, I think that "Activity is the only special resource without
get_datamethod, but instead has some other methods that return activity data" is not a great API design. IOW: current capabilities of theyagnaAPI should not definegolem_apiinterface. --> This requires some thinking.