JohanLarsson
JohanLarsson

Reputation: 485

WebAPI services architecture

We have a web api service layer (SL), where each part of the business layer has its own web api application. Currently we are in the process of adding administration features to our api. Admin features can be related to both Engine1 and Engine2, etc.

I'm considering adding a SL.Admin app to expose the admin api. The business Layer is devided by "module", i.e. BL.Main, BL.Engine1 and BL.Engine2. Since I'm using autofac as a factory I want to devide for example SL.Engine1 registrations into two modules, i.e. Engine1Module and Engine1AdminModule. This way I can register the Engine1Module in SL.Engine1 and Engine1AdminModule in SL.Admin.

our api would look something like (using a reverse proxy)

/api/engine1/foo/bar/featureA?varX=x
/api/engine2/foo/bar/featureB?varY=y
/api/admin/engine1/foo/bar/featureC?varZ=z
/api/admin/engine2/foo/bar/featureD?varT=t

I'm wondering if this is a good strategy or should I be doing my homework more carefully? :)

Upvotes: 1

Views: 49

Answers (1)

Daniel L
Daniel L

Reputation: 26

It's always a good design choice to keep things in separate services. In my opinion you could go even further (if possible) to make the admin service independent of the engine business layer, meaning that you separates out the admin functionality in it's on business layer. In that way you get services that is more independent of each other.

Upvotes: 1

Related Questions