0

We are creating REST API which will be consumed by Web and Mobile users.

My question is: do we need to consider user interface before designing the JSON structure?

For example, we have one resource Company. A Company has multiple customers with its experiences. We created API company/{company_id}/customers to fetch the list of customers for a particular company. In response, the API is sending a list of customers with basic details like (id, name, address, email, phone).

Is a best practice to send customer experiences with customer detail?

Currently while fetching customers, we are sending only basic details of customers without their experiences. When we refer user interface for mobile and web it's showing customer's experience with customer detail in customer listing screen.

So now is that a best practice if we make multiple small REST calls to get other information?

  • 1
    That has nothing to do with REST. – Rob Jan 6 '18 at 15:22
  • 1
    @Rob I think this question can be considered in a context of REST best practices. Mainly it is about how much details you should send together with your main data in a RESTful reply. – Vladislav Rastrusny Jan 7 '18 at 9:19
  • @VladislavRastrusny REST has nothing to do with content. – Rob Jan 7 '18 at 10:59
  • Ok sorry for bad title but thanks a lot all .I got my ans – mcd Jan 7 '18 at 11:01
  • @Rob But still this question is interesting and deserves an answer. If you don't like the title or the tags you could propose changes to them (like I just did since I agree - this doesn't relate to REST at least directly) instead of leaving meaningless comments. – Vladislav Rastrusny Jan 7 '18 at 18:49
2

I do not regard sending various details together with main data by default as a good practice. Instead, use some option with name like _with to list all child entities you want to get in an API response. For your example it might be something like: company/{company_id}/customers?_with=experience,purchase

Usually I try to map _with items to my domain model (Customer is a main entity, Experience and Purchase are related to it).

I do not recommend using small REST calls to fetch details because of performance reasons. REST call is an expensive thing.

  • thanks a ton. we refer stackoverflow.com/questions/3138371/… url. It suggest to make one call to fetch all data instead of making multiple calls for child. What if one customer have more than 1k purchases? How to handle this scenario? – mcd Jan 6 '18 at 9:33
  • 1
    Implementing pagination – Laiv Jan 6 '18 at 11:38
  • in addition to the @Vladislav answer, there's also the concept of Backend for frontends. It's not as sophisticated and powerful as the solution purposed here, but it's an alternative easy to implement that can help you out to reconcile the requirements of each client (mobile and browser). In another hand, remember that the more requests are required to complete the data in the client-side, the more traffic in the server-side. You have to find the balance between volume of data and volume of request to the server – Laiv Jan 6 '18 at 12:03
  • 1
    @mcd Implementing filtering and pagination. There should be no reason your application needs all entries at once. Probably, some filtering should be done. – Vladislav Rastrusny Jan 6 '18 at 17:57

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.