API Split for creating object with inheritance and behaviors

Question

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:

1. Have one single API and handle the implementations and behaviours in that API.
2. Have N APIs for N implementations.
3. 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.

Answer 1

Judging from your example I'm not sure what properties of furniture are behaviors and what are implementations. Still, I'm not a fan of the 1st approach as it might be a case of premature abstraction. Consider the case when chairs or sofas have soft casing (I'm not sure whether this is the right word since I'm not a native speaker) in places where your sit, while tables don't since tables are not designed for sitting on them.

This is the reason why I prefer having a separate endpoint for each furniture type with its own contract.

Regarding your concern about common logic between different furniture types my opinion is that API layer of the application is not the place where you should handle it. Furthermore business logic should not be hanled at API layer at all IMO. Rather at BL layer if you're practicing n-tier architecture, or domain layer if you're a DDD practicioner.

On above mentioned layers you can handle logic duplication by any means you want. For example by utilizing dynamic polymorphism i.e.

public class SterngthCalculator {
  public decimal Calculate(ILeggedFurniture item) 
  {
    //do your stuff
  }
}