I have a web service which is exposed to UI owned by our team. This web service is responsible for creation of objects and saving it in the DB (NoSQL Database). The object being created has multiple implementations and behaviours which can be changed at runtime. How should the APIs be split? I have three approaches in mind:
- Have one single API and handle the implementations and behaviours in that API.
- Have N APIs for N implementations.
- Have N * M APIs for N*M implementations and behaviours combinations.
In first approach, API would be overloaded with decision points for each property/ behaviour. In second approach, I see the issue of sharing common logic for behaviours across N implementations. In third approach, for any new implementation or behaviour, I would need to make N or M new APIs.
Example: Service is responsible for creating various Furniture objects. a) A furniture can be of type Chair, Table or Stool etc. b) Object can be of different material e.g. Steel, Wood, Iron (more in future) c) Each object can have different number of legs. I am assuming the formula to calculate strength for K-legged object will be same for all objects irrespective of its implementation.
UI would know what shape to create (e.g. table) with material (wood) and legs (six for example) and would call backend API. Thanks in advance. Please let me know if more details are required.