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?

5
  • 1
    That has nothing to do with REST.
    – Rob
    Jan 6, 2018 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. Jan 7, 2018 at 9:19
  • @VladislavRastrusny REST has nothing to do with content.
    – Rob
    Jan 7, 2018 at 10:59
  • Ok sorry for bad title but thanks a lot all .I got my ans
    – mcd
    Jan 7, 2018 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. Jan 7, 2018 at 18:49

2 Answers 2

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.

4
  • 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, 2018 at 9:33
  • 1
    Implementing pagination
    – Laiv
    Jan 6, 2018 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, 2018 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. Jan 6, 2018 at 17:57
0

The best I've seen (if we do not go into GraphQL and graph-based formats) is a mechanism for deferred entries in the OData. Use query string to select what needs to be fetched in full (there can be custom filters, pagination, etc). For the rest - only URIs are fetched (this also provides for HATEOAS: Application will not need to construct URLs).

This way an application will be able to choose what is the portion of information if wants at first and then fetch extra information, for example, if the user opens some previously closed tab.

While complete OData may seem like quite heavy, I think whatever solution can be found for this will just emulate that approach in ad hoc manner.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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