Lets say you have a typical C# .netcore webapi you are wanting to use in a microservices architecture environment. It uses entity framework connects to a SQL database, has models and DTOs.
If you want to separate the 'restfulness', the actions of actually responding to the individual GET/PUT/PATCH/POST/DELETE/ETC methods, from the data models (and into microservices) what approach would you take?
IE instead of having to create 100 microservices that each expose the same exact RESTful functionality within the APIs but each have their own specific data models and DTOs, id want to create 1 API that exposes restful GET/PUT/PATCH/POST/DELETE/ETC and separate it from static models, dtos and entitybuilder configurations. So i'd have 100 microservices concerned with passing data to the 1 REST microservice to get whatever job I need to do done in a dynamic fashion.
I am not super experienced with object oriented programming methods and I thought maybe it would be possible to have my CRUD microservice that my child microservice talks to (through an API gateway or some other method that I haven't worked out yet) pass a set of models, DTOs and entity framework entitybuilder parameters into the CRUD microservices Program.cs's Main method?
I am on the right path here?
Thank you in advance for any advise or helpful examples!!!
You don't. What you describe is still having a single monolith and putting 100 microservices as a facade. That makes about as much sense as ordering a large pizza and a dozen small salads as dessert because you were told that having a small salad for a meal would help you lose weight. That's not how that works.
Either look into microservices and what you gain by using that architecture, or go with your single service that does it all. Both might be valid choices, just don't pretend you are doing the other one too.