First And Second Level Resources - sreeise/graph-rs-sdk GitHub Wiki

A first level resource is one only those resources who have their name/path such as /teams at the very start of the path or is first in the path. These resources are referred to in codegen as first level resources and that is how they will be referenced from here on out.

A second level resource is:

• Any part of the path that comes immediately after the first level resource in the path AND
  • is not an id specific part of the path such as teams-id in the path /teams/{team-id}
  • is typically covering 5 or more request paths. You won't want to waste time generating methods for a second level resource if all it has is two methods generated. Those methods can just go in the top level resource which in this case is teams. Meaning the methods should just be generated as part of the teams api client.

Here is some examples:

The schedules paths of teams has many paths and requests but here are just a few:

"/teams/{team-id}/schedule/swapShiftsChangeRequests"
"/teams/{team-id}/schedule/swapShiftsChangeRequests/$count"
"/teams/{team-id}/schedule/swapShiftsChangeRequests/{swapShiftsChangeRequest-id}"
"/teams/{team-id}/schedule/timeOffReasons"

As well as the primaryChannel paths that we find when printing out paths containing teams:

"/teams/{team-id}/primaryChannel/sharedWithTeams/{sharedWithChannelTeamInfo-id}"
"/teams/{team-id}/primaryChannel/sharedWithTeams/{sharedWithChannelTeamInfo-id}/allowedMembers"
"/teams/{team-id}/primaryChannel/sharedWithTeams/{sharedWithChannelTeamInfo-id}/allowedMembers/$count"
"/teams/{team-id}/primaryChannel/sharedWithTeams/{sharedWithChannelTeamInfo-id}/allowedMembers/{conversationMember-id}"
"/teams/{team-id}/primaryChannel/tabs"
"/teams/{team-id}/primaryChannel/tabs/$count"
"/teams/{team-id}/primaryChannel/tabs/{teamsTab-id}"

This tells us that both schedule and primaryChannel will be second level resources.

So what does this mean exactly? In codegen we will want to separate these second level resources into their own api client impl and store them in the team's directory. Why don't we just store all methods in one single api client? For a detailed explanation on that see Why seperate clients by path

The OpenApi object has a method that can return the second level resources of a given path as well and it is generally pretty accurate but its still necessary to make sure that the second level resources are ones that actually need to be generated and also that there are not more second level resources that are missing:

use graph_codegen::openapi::OpenApi;

fn main() {
    let open_api = OpenApi::default();

    // Returns BTreeSet<String>
    let resources = open_api.first_second_level_resources("teams");
    println!("{:#?}", resources);
}

This prints out:

{
    "channels",
    "installedApps",
    "primaryChannel",
    "schedule",
    "tags",
}

The only one not currently implemented as a separate client is installedApps. Those methods are part of the TeamsIdApiClient. installedApps could easily be implemented as a seperate client as well. I chose not to change installedApps because those methods were not in conflict with other methods, such as same method names, and there wasn't a large number of requests but the number is around 9.