1

I am mobile developer and always have one particular fight with my web-service/backend developer which believe in designing restful api.

Issue: As per Restful design,every api should be atomic in nature,but this create alot of problems to clients especially mobile based. Since to perform any operation like opening of a particular page, i might have to make N calls to load the data which gives a very bad user experience .

One valid user-case to explain : In an e-commerce application,load a product detail page. In this page we have to show product detail , inventory information , offer description , related products , recommended product etc,and as per restFul each one them could be a individual api and loading each of them individually will kill user experience and making a aggregate call is against Restful principal.

Can anyone tell me how you have solved/to solve this problem ?

  • 1
    Do you have an actual, documented performance problem due to multiple calls, or an opinion that multiple calls will be nonperformant? – Eric Stein Aug 31 '16 at 17:39
  • REST alone is pretty primitive. It doesn't necessarily provide a means of doing rich query (e.g. with joins, etc.. across multiple resources), or transactional updates across multiple resources, leaving developers to reinvent the wheel with http & url language for specifying these things. Have a look at OData, which layers on top of REST and has these things as well as multiple requests per message, batch, etc.. – Erik Eidt Aug 31 '16 at 17:44
  • No, i don't have any stats to put my case but this very common to understand , mobile phone don't have similar network capabilities as compared to laptop so we have to always consider latency and each network connection request give a direct hit to battery of the device ie less network call is favourable . – Code_Life Aug 31 '16 at 17:45
  • See how Netflix does this with Api gateway: microservices.io/patterns/apigateway.html here is about your exact use case: dzone.com/articles/building-microservices-using – Luc Franken Sep 1 '16 at 8:38
1

Something to remind the backend developer of: REST doesn't say anything about the size/complexity of the objects in the payload, only about the atomicity and stateless nature of the transactions. It's entirely allowable to have a path of the form /product/{id}/details which returns a payload rooted in the same object as /product/{id} but with additional information possibly pulled from multiple tables. You can use the path for simple-to-express variations, or query-string variables if you've got complex requirements for optional additional information. On the PUT side, a PUT to /products/{id} could either look at what's present in the payload and update tables based on that or it could only update the base product and require additional path segments and/or query-string variables matching the corresponding GET to update additional tables. The choice depends on what makes things simplest and most straightforward/understandable for the application.

An internal API like this exists to serve a purpose. If using it's making things harder rather than easier, that's a sure sign something's not right with the API.

0

The job of an API is to provide external systems access to information. REST proposes modeling that data into resources, with suggestions on how to work with those models. In well-written APIs, the resources are built to make the client's job as easy as possible. In a public API, that's Hard. In a private API, it's a lot easier.

You sound like you're trying to force a generic API on a single internal customer. There's nothing wrong with allowing a GET /product-details/{id}. Include it as a link off of the product (preferable), or use the same ID for product and product-details. That resource can hold exactly what information the product details page needs. If the user decides to update the product, the client can call a GET /products/{id} for the full details and then a PUT /products/{id} to do the update.

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.