I just watched a video, that says it's a bad practice to create API like that

/applications/getUser

/applications/deleteUser

/applications/getUserAndWeather

and from what I understood, it's a good design to create something like User and initialize post, get, put, delete properly.

but what if in my android application there is a page that shows all users in addition to weather, should I combine those two independent resources into one single API called UsersAndWeathers(GET) or create one called getUsersAndWeather. or should I create two separate endpoints and let android application calls both of in parallel?

I know all solutions would finally work, but which is the best design?

CodePudding user response：

It's good to make small single-purpose API endpoints, because not every client might need both at the same time, the results might appear at different speeds, and might have different rules around when you need to refresh them. Just generally you don't want to combine every API response in one giant one.

HTTP requests are not that expensive, so your default should be to make 2 endpoints like

/users
/weather

There are certain cases where combining responses is a good idea, but you should only consider making these combined endpoints if you have such a reason. Until then, do the simple thing.

If you do find that reducing requests is something you need to do later, I would recommend you look into standard JSON response formats like HAL and JSON:API as they all have built-in syntax to support this use-case.