Web Api - Controller Per Database Entity or per UI Screen

Question

I am using web api in my project to expose data which in turn is intended to be used by a mobile application and a web application.

I want to know what is the best practice to expose data.

For instance, I have a customer registration form in which I am capturing Customer details including city and country.

One way to expose the data is to have separate Controllers for cities and countries and make separate calls to both on the customer registration form in order to load the data for cities and countries.

The issue with this approach would be that if I have to load hundred fields, I will have to make hundred different call to the api to load the data and hence the application will be slow.

Second approach would be design the api layer in such a way that one controller expose all the lookup data (cities, countries) required for a form/screen (customer registration). In this case I will have to make a single call to the api to get all the required data.

It feels like, using the second approach I am violating separation of concern.

Which way to go?

Answer 1

Can't you just split UI and API layers?

I do not think you should create API to fetch countries or whatever else side-references if they are not core parts of your domain.

I guess you should just expose api/v1/users resource endpoint for user registration, which expects a valid user data for registration.

Plus you should expose /users UI, which will generate full UI, including all the lists you need and present it to the user. This UI controller will call your domain model internally, not via API to get all the details, needed to generate UI. And then UI on the client side will call your API controller with user selected data to register user.

Will that suite your development model?