RESTful Api for Mobile Clients

Question

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 ?

Answer 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.

Answer 2

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.