I have a Hotel entity which can have many address and many image objects i.e. they are one2many related with the hotel.

The question arises while fetching and saving the linked resource.


  1. I load the resource which is Hotel here which has the ids array of the address as well as image, these address contains the unique ids for each related resource, after hotel is fetched the next request is made to fetch address and images either one after another or in parallel (parallel may be better because they are not related). The downside is that there are three network requests(one for hotel and then addresses and images) and has the downside of showing the partial information such as all address not fully fetched in case server is down.
  2. When the hotel resource is requested the application on server does all the work and with help of database joins all the information is sent in one go probably taking more time. Now, in this case the resource has an array of actual address and image objects.


  1. In case of new resource all the information is passed to the server at one go i.e. resource with the array of address and thumbnail links. In this case linked resource are saved first i.e. address is saved first then its id is linked to the resource and then resource is saved. If the address is failed to save we rollback whole action and consider it failed and ask client to try again.
  2. For update I have to give some more thought, maybe design the UI such that only one linked resource can be updated at a time.

I would like to hear if there are any better approach or which of my approach is better and why?

  • What "better" means for you in this specific context? Efficient? What would you like to achieve? For instance, fetching with option #1 could be more suitable in situations where either images and addresses are not necessarily required every time the resource is requested. Or if the resource is requested quite often so that option #2 has a negative impact on the server-side due to the resources consumption. Could you provide us with more context?
    – Laiv
    Jul 13, 2017 at 6:56
  • I started to answer this but stopped because it turned out the scenarios you describe are just not clear. I imagine this is why you get little response. People just give up in annoyance. Jul 17, 2017 at 5:17
  • @MartinMaat what is not clear? It's better to teach than slap in frustration.
    – CodeYogi
    Jul 17, 2017 at 5:19
  • I do not understand where the ids come from, whether they are already known by the client and the client needs only one or two images, or if it is a browsing scenario where each image just happens to have an id to be displayed and everything will have to be fetched anyway. It matters what the typical usage scenario is. I am not slapping, just trying to help understand why little members seem to bother. Jul 17, 2017 at 5:26
  • @MartinMaat as told a hotel/room can have many images. So while fetching hotel details we can fetch images ids too.
    – CodeYogi
    Jul 17, 2017 at 5:29

2 Answers 2


Your persistence layer can probably join faster than you doing multiple fetches and joining inside the application layer.

You should figure out your default behavior which handles 60% of all needs and then add an optional parameter to handle the remaining 40%. If you consistently need all the images and addresses with the resource then your default is to return all of them with a single request to that resource. Then define a select behavior where you specify which data you want to retrieve for the remaining cases.

I believe #2 would be the better of the two as #1 introduces useless indirection.

As for saving, it depends on the context of the application needs. Does the resource require at least 1 address and image? Are those resources optional? Can you add more images/address later?

Ultimately, the server should make the client's life easy. It would be easier to have the ability to both create the entire resource in one go and add new resources directly.

  • Yes, the resource should have at least one address and 0 or more images.
    – CodeYogi
    Jul 8, 2017 at 4:24
  • would you like to add more details?
    – CodeYogi
    Jul 12, 2017 at 17:22
  • What is the problem you're having exactly?
    – jakedipity
    Jul 15, 2017 at 10:23

I would go with the approach that scales better as your database grows. Take the extra call per session and save on the initial performance hit and memory use at the client side.

I am not sure if this makes sense, I do not fully understand the question.

  • What you didn't understand?
    – CodeYogi
    Jul 19, 2017 at 2:21
  • I have to analyse your comments to learn this is probably about a web application offering a collection of hotel rooms with a number of photographs for each room/address. So the usage scenario is not obvious while it matters a lot for the way to handle things. The question lacks context and introduction. Jul 19, 2017 at 2:38
  • What about the couple of starting lines?
    – CodeYogi
    Jul 19, 2017 at 2:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.