0

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.

  • Your question is a bit confusing. By different APIs do you mean different endpoints? More context would also be useful. What processes are arbitrarily different per-object? – robinsax May 6 at 8:24
  • Yes, API means different endpoint. An object can have different color, different material or varied number of legs. For e.g. UI client would ask to create a chair with red color, steel material and 4 number of legs OR it may ask to create a table with brown color, wooden material and 5 number of legs. – dka72 May 6 at 9:08
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
  }
}
| improve this answer | |
  • Thanks! I had similar thought process. One thing I was unclear that why the Sofa/ Chair/ Table can't act as behavior? Typically, these are types of shape. How do we draw this distinction? – dka72 May 15 at 18:36
  • "One thing I was unclear that why the Sofa/ Chair/ Table can't act as behavior?" - I'm really unsure what do you mean by this. – Bohdan Stupak May 18 at 14:42
  • My bad, I should have been more clear. I want to ask why can't FURNITURE class have the property (field) which describes name of shape (Sofa/ Chair). How do we decide this (shape) has to be subclassed and not kept as property in class. – dka72 May 20 at 18:27
  • My thinking is that having all in a single class will make this class possess some properties that only some types of furniture have i.e. soft casing. Also, this will force code to have a giant switch operator that checks the field type. And this is quite unpleasant IMO. – Bohdan Stupak May 21 at 10:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.