I want to expose most of my business layer methods to a Web API project to allow for broader consumption.
One idea is to have one Web API controller per resource.
The other idea is to have one controller per logical business part and use attribute routing to expose the relative methods.
I like the second approach, that results to less controllers.
What are the disadvantages of NOT having one controller per resource?
Additional Info:
This API will live in an intranet and will serve support applications that need data from our 2-3 master applications (ERP,Payroll,Barcode e.t.c)
A resource for this APi would be business entities that are defined in our business layer assembly. They will be simple objects and complex ones. Examples:
- Inventory Items
- Customers
- Items per Customer
- Current loading pickslips
- Present production data
e.t.c
Example:
I want to expose methods like GetCustomerListByArea
or GetItemsListPerCategory
.
What then? Should i create another controller or use custom controller actions and attribute routing and put it in the existing controllers?
A link with some more info:
REST vs. RPC in ASP.NET Web API? Who cares; it does both.
Very nice , rather old, article explaining my question. But it does not go deeper in actual saying how to orginize controllers. In areas? Or just folders?
See Question&Answers more detail:
os 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…