Separate HTTP requests for each dropdown or a single request for a fat FormViewModel?

If the view which serves for creating an item contains some dropboxes / checkboxes / whatever with values from the server, should it send separate requests for filling up those controls with values (one request per each collection of data) or it is better to have a single API endpoint that returns all of the necessary data for filling up the form on front-end?

For the sake of simplicity, I've simulated here an example: Say we're building an app for a car servicing company where clients can make appointments:

Should the front-end app make 2 get requests to api/models and api/services, or these collections can be returned from the server in a single response (from api/appointments/createformdata), What are the best practices regarding to this?

Well, since in your example, both combo boxes need values, then I would load up on first page load. There would be no need for separate requests unless those combo boxes are dependent on data in the form, and then in that case you have no choice but to wait for user input to determine that.

so, say you have two combo boxes, and the 2nd one is cascaded by the 1st combo choice? Well, the first combo box does not change - so load it up at page load time, and you have to do that anyway. No use writing out separate events or code to load that first combo that MUST be loaded in the first place.

however, the 2nd combo box? Well, since its values are based on the first one, then once again, you have no choice, do you?

So, I don't see any real use case, that if two combo boxes are independent to each other, then I see next to no reason why separate requests would be required, and that just loading up both combo boxes on first page load would not suffice here? (then you don't need ANY separate requests).

Now, if there is some kind of tab, or UI and the user can't see nor use the combo boxes right away, or may never even select say some tab out of a tab control? Well, ok, in that case then you speed up the page load by not filling out the combo boxes until such time the user gets to that part of the form (maybe some pop dialog, or maybe some kind of wizard steps).

But, once again, if the two combo boxes are not dependent on each other? Then I see no reason to use two requests or events to load up both of them. But then again, it would beg the question as to how you did in the past load up the combo boxes anyway?

I mean, if each combo box was some ajax call, then keep using two of them, and keep the two requests. Since attempting to merge, or put two ajax calls that fill out two combo boxes as one call is a pain, and does not follow a re-use design patter. The result is messy code, and worse force you to write code that does two things.

I mean, if you build a nice general routine to call + fill out the combo box, then continue to use that code to fill out the 2nd one. I would not blow up really nice working code to somehow fill out two simple combo boxes on a page and attempt to use one request for that filing out of the combo boxes.

And as I stated, if the combo boxes are in plain view from the start of the page load, then code behind on first page load is the place to do this unless some rather huge performance issue were to crop up. As a result, you now don't have ANY separate requests to fill out the combo's, do you?

But then again, a combo box is good for what, 30, maybe 50 choices tops, and after that, you need a different UI, and thus once again, you don't have a problem performance wise by doing this either way, do you?

And if you are trying to fix or avoid a performance problem? Then you putting too many choices into the combo box, and that is the wrong ui choice, and then once again, you don't have this issue, do you?