Generated SDKs group the actions based on the 'use cases' structure under which they are presently grouped. This is good for explaining the motivations for the OTAPI actions but doesn't yield the most friendly client-side SDK experience. e.g.
token = '37A6259CC0C1DAE299A7866489DFF0BD'
result = use_case_driver_route_and_directions_done_controller.follow_fleet_log_events(token)
The action follow_fleet_log_events can be used for multiple use cases not just Driver Route and Directions Done. The client side developer using this SDK will find it confusing in all but the one case where the use case matched (and even then, the grouping name is strange).
The actions should be re-organized into logical grouping with an eye on client-side SDK development experience.
Along with #50, the individual actions should remain cross-referenced from a use-cases section in the document in order to maintain the explanatory benefits of presenting those associations.
Generated SDKs group the actions based on the 'use cases' structure under which they are presently grouped. This is good for explaining the motivations for the OTAPI actions but doesn't yield the most friendly client-side SDK experience. e.g.
The action
follow_fleet_log_eventscan be used for multiple use cases not just Driver Route and Directions Done. The client side developer using this SDK will find it confusing in all but the one case where the use case matched (and even then, the grouping name is strange).The actions should be re-organized into logical grouping with an eye on client-side SDK development experience.
Along with #50, the individual actions should remain cross-referenced from a use-cases section in the document in order to maintain the explanatory benefits of presenting those associations.