Last post Feb 25, 2014 05:59 AM by amitpatel.it
Feb 20, 2014 02:49 PM|danp276|LINK
I'm coming from WCF where I'd put about 100 methods or contracts into 1 interface/file. I'd personally like to have 1 large file than 100 small files.
Is this frowned upon with WebAPI? I guess i can change the routing by changing the variable ids, but there doesn't seem to be a great way to do it in web api 1.
Should I just give in and make a bunch of small files?
Feb 21, 2014 01:17 PM|sukumarraju|LINK
It is all about "source and your API" management.
It doesnt make sense when an API shows 100s of operations
Feb 21, 2014 03:46 PM|danp276|LINK
Well maybe not 100s, but for example. Say I'm getting people's cats and dogs.
Is it good practice to have:
In the same controller, or would you make different controller files for those.
Feb 23, 2014 02:09 PM|damienBod|LINK
There is no right or wrong to this. The main thing should be that it is easy to understand your code so a second person could continue with development if required. A controller with a 100 methods seems like a lot, but by it's nature controllers are flat.
Maybe you code separate these methods into separate child controllers with a single responsibility in each class. Another possibility would be to use Attribute Routing, grouping the methods were you can but using separate controller classes (same base url).
If you separate your methods to much, your code becomes harder to understand...
With so many methods, you should have no logic implemented in your controller(s), the methods should just call business methods from separate classes. This reduces the complexity of your controller, which makes it easier to understand.
hope this helps
Feb 25, 2014 05:59 AM|amitpatel.it|LINK
In general you can add n number of methods or web method in api but as general practice we can add methods based on related operation and if that is comes more than 20 or 25 then we should create sepearte web api controller with differnt entity to make code