How to avoid creating many similar classes in ASP.NET Core web application?

I have been working on multiple ASP.NET Core based web applications so far and there is always this one issue I come across. Example:
I want to create a controller that provides simple CRUD operations for a ressource (e.g. a "Product"). When implementing an endpoint to create the ressource, I need a class containing the properties of that ressource which I expect to receive from the caller. In this case, I do not need to get an ID because the ID is determined by the database when the new entity is created.

When implementing an update endpoint, I technically need the same class but this time with an ID, so the application knows which entity must be updated in the database. When implementing an endpoint to get a single or a list of all existing ressources, I also need technically the same class with the ID included (since I want to return the ID to the caller so it can uniquely identify each entity).

My options are as follows:

1. Create a separate class for each endpoint where I need a different "flavor" of it. This way, I end up with multiple classes that look extremely similar and can become difficult to manage sooner or later the more complex the project becomes.
2. Use a single class and make all properties nullable which are not always needed in every endpoint. This way, I have less redundancy overall but I have some overhead in the endpoints where do not need the additional properties. I also have problems when using swagger because it would list those properties in the endpoint documentation while they are in fact not needed at all in that endpoint.
3. Remove all properties from the class which are not always needed and provide them separately when needed. This works in many cases, but is especially ugly in GET-endpoints, e.g. where I would like to return the ID as property of the returned objects.
4. Use inheritance and create some sort of "base" class which contains only the required properties. For endpoints that need an ID or other property, sub-classes like "ProductWithId" are created and used. In simple scenarios, this seems like a good solution to me but as soon as it gets more complex, the names of those sub-classes can become pretty unreadable (e.g. "ProductWithIDAndWithoutFieldXYZ").

I know that this might be a bit opinionated, but is there any common approach to this problem that works in many or even in all cases? Are there any other options which I did not consider so far that would solve this problem?

Yes, it's opinionated. I'll put my opinion here.

You mentioned that keeping properties as null and using the same classes may cause overhead in your system. If it is just the ID property that you are worried about then Worry no more. It is Not Overhead to your endponint (Considering servers of this generation). I've seen many enterprise applications use the same classes for both command and query operations.

If you have more than a couple of such properties, still I think it is fine to use same class by keeping those properties as null when not in use. Personally, I've seen many microservices that we are building and consuming that does the same. If the number of such properties are huge and you're using SQL based database, you may need to work on modelling the data properly using Normalization Techniques.

If you still seek other options other than solutions you listed, using GraphQL can help you to keep the same class and return exactly what's required to the client. I know it's an over-over-kill implementing graphql just so that you can avoid overhead with the ID property. It's a big decision to take in the software architecture matters. You can only go for it once you understand what advantage it brings over REST other than what's mentioned above and suits to your requirements. GraphQL may solve your bandwithdth concerns but it has its own drawbacks as well.

Happy to see if there is any code level tricks that address the question.