The BaseCollectionRequest class exhibits a simple flaw in that sufficient type information should be supplied in the generic types of the class so that the BodyType is not required.

Example usage is:

User u = new User();
client.users().buildRequest().post(u);

When you delve into the source around that you see that the post method being discussed is passed a serialized object type of User.class. That typing should be redundant because the types T1 and T2 in BaseCollectionRequest should already carry the User type as part of their signature.

This is a marker for me of sub-optimal modelling in the generated code and we get code smells like this BodyType generic parameter on a method.

To demonstrate with more detail, when post in the example above it calls (eventually) post on this class:

BaseUserCollectionRequest extends BaseCollectionRequest<BaseUserCollectionResponse, IUserCollectionPage>

Both BaseUserCollectionResponse and IUserCollectionPage clearly are about the User type and the second one makes explicit mention of User in its signature because IUserCollectionPage is a IBaseCollectionPage<User, IUserCollectionRequestBuilder>.

So can you see why it seems ridiculous to pass the type User again to the post method and if the relationships were modelled properly I think we would discover type bugs in the existing code (where we pass an object to the post method on a collection that does not match the expected type for that collection.

The fix for this is that BaseCollectionRequest should not have two independent type parameters T1 and T2 but one T. In our example this corresponds to User. The constructor would then expect the response class and collectionPage class to have something to do with T:

public BaseCollectionRequest(final String requestUrl,
                                 final IBaseClient client,
                                 final List<? extends Option> options,
                                 final Class<? extends ICollectionResponse<T>> responseClass,
                                 final Class<? extends ICollectionPage<T>> collectionPageClass) {

Note that ICollectionResponse and ICollectionPage don't exist yet but generated code would be expected to carry those new interfaces where appropriate.

@NakulSabharwal the use of the term "body" in this class is a bit confusing, would be nice to sort out some day but the main issue I have is in that long comment above. That's the change that will fix #66, not this PR which is more of a bandaid that continues to cover up possible type safety problems.

To fix this requires work in the generator. My contributing there is made difficult because of microsoftgraph/MSGraph-SDK-Code-Generator#141. I just want to change a template then generate java classes in one command line call. I would then copy the new java classes to the msgraph-sdk-java to test.

@davidmoten the use of term "Body" we can think upon. And the post method in above discussion, being a protected method is called by the following classes only.

BaseDeviceCompliancePolicyAssignCollectionRequest
BaseDeviceConfigurationAssignCollectionRequest
BaseDirectoryObjectCheckMemberGroupsCollectionRequest
BaseDirectoryObjectGetByIdsCollectionRequest
BaseDirectoryObjectGetMemberGroupsCollectionRequest
BaseDirectoryObjectGetMemberObjectsCollectionRequest
BaseDriveItemInviteCollectionRequest
BaseCollectionRequestTests

If we want to remove the use of generic BodyType in post(final BodyType serializedObject) of BaseCollectionRequest.
For example in class BaseDeviceCompliancePolicyAssignCollectionRequest, in method post the body variable is of DeviceConfigurationAssignBody class which is not a child class nor itself type of T2(in this case IDeviceConfigurationAssignCollectionPage). Which may require some change on the BaseCollectionRequest(Handwritten class). Can you give example what change you are suggesting in generated files ?

@NakulSabharwal I gave the suggested changes to BaseCollectionRequest in my comment. You make those changes and start following the compile errors to see the other required changes. If you need more detail I will make a PR to demonstrate the change required.

@davidmoten Thanks for the pull request to demonstrate the suggested fixes. This post method is not exposed to the user of the SDK and is an internal method, having no impact on user experience. We agree that this is an issue and needs to be fixed. We will discuss this enhancement request internally and prioritize this work item. @deepak2016 @darrelmiller