Group methods into "sub-resource"

[Jericho]

Currently, all methods are grouped into ~20 so-called resources (such as meetings, webinars, phone, etc.). The problem is that each of these resources can have a high number of methods which is not great for discoverability and clarity. For example, there are approximately 60 methods in the Meetings resource as of this writing, and we have implemented only about 50% of the meetings related endpoints from the Zoom API. This means that, when we implement all endpoints there will be probably more than 120 methods in the resource.

@MacgyverH suggested we should create "sub-resources" in the exiting 20 or so resources to logically group methods. These sub-resources would roughly correspond to the categories in the Zoom API documentation. If we look at the Meetings resource as an example, the documentation groups all endpoints into 19 categories such as:

• Archiving
• Cloud Recording
• Devices
• H323 Devices
• In-Meeting Apps
• In-Meeting Features
• Invitation & Registration
• etc.

From a developer standpoint, this means that instead of invoking myZoomNetClient.Meetings.GetSurveyAsync(...) you would invoke myZoomNetClient.Meetings.Surveys.GetAsync(...)

I am conscious that this would be a painful breaking change. To ease the transition, I would leave the existing methods for a certain period of time, and decorate them with something along the lines of `[Obsolete("Please use Meeting.Surveys.GetAsync")]. This would ensure that Visual Studio would display a warning to the developer about the breaking change (I am assuming other IDEs do the same thing) and give them a reasonable amount to make the transition before the methods they have relied on for so many years are permanently removed from the library.

[Jericho]

There are some cases that feel weird: in the API documentation the "Meetings" section has a category called "Meetings" where all the Get, GetAll, Create, Delete, etc. endpoints are grouped.

According to the logic I explained in my original comment this means that we would have a "Meetings" resource with a "Meetings" sub-resource. To retrieve a meeting you would invoke:

var myMeeting = await myZomNetClient.Meetings.Meetings.GetAsync(...).ConfigureAwait(false);

The double ".Meetings" feels very weird.

[MacgyverH]

Hmm, I agree that it does feel a bit weird. I think it could make sense to potentially have these in the parent resource, but that does make things messy. And make these API calls harder to find if everything else is in sub-resources.

[Jericho]

Maybe if we find a better name for the Meeting resource, something like "OnlineEvents" (I don't really want to use the word events because there is such a thing called Events in the API). "OnlineGatherings" maybe? "OnlineSomethingOrAnother"?

The call to retrieve a meeting would become:

var myMeeting = await myZomNetClient.OnlineGatherings.Meetings.GetAsync(...).ConfigureAwait(false);

Would that be any better?

The more I think about this, the less convinced I become that organizing methods into sub-resources is a good idea after all.

[MacgyverH]

I do think that the sub resources would benefit everyone long term, both users, and maintainers. The only alternative I have come up with more would be like

myZoomClient.MeetingsAPI.Meetings.GetAsync(...)

or something like that I'm still brainstorming alternative naming conventions outside of that.