0

I need your help. I think about design of backend API for mobile application. Should it be REST-like or something else?

For example imagine that we create some social network app. There is one page. The page contains:

  1. User information (some fields from User domain)
  2. Collection of user messages (not all fields from Message domain)
  3. Numeric value - count of guests
  4. Numeric value - count of posts on user wall

I see this options:

  1. Create endpoints for all 4 domains and call 4 requests:

    GET /users/111?fields=id,name,email
GET /users/111/messages?fields=id,text,date_created
GET /users/111/guests/count
GET /users/111/posts/count?filter=news

  2. Create one method for getting all this information by one request

    GET /GetUserProfileInfo?userId=111

  3. Other options

That do you think? Which variant is better? What about performance? What is the best practice for it?

Thanks.

Oleg Mishenkin
  • 39
  • 5
  • what is the framework used to build the front end!!? – Aravind Sep 01 '16 at 09:20
  • I think it does not matter. In this example I talk about mobile app, but question is about conception. – Oleg Mishenkin Sep 01 '16 at 11:27
  • I hope you know that the mobile applications can be built using many frameworks for example javascripts, java c#, xaml etc. How ever the function call may vary and security will also vary and it will be easy if you can tell me what programming framework your using. – Aravind Sep 01 '16 at 12:49
  • Currently I used two technologies: Xamarin and ReactNative. – Oleg Mishenkin Sep 02 '16 at 02:26

1 Answers1

0

The question you are asking is rather broad but hopefully this can set you in the right direction.

I would go with a RESTful interface, I have experience connecting to both REST and SOAP API's from mobile apps and REST is definitely easier.

When it comes to the endpoints first I think you might want to revisit option one. For example if message is separate resource you might want to go with /messages followed by search parameters like /messages?user=111. But this really depends on what resources your are trying to represent.

For the second option I would go with a verb, you can only make a userprofile based on a user. And since it combines various aspects of a user the same way for each user it is more than just a query or a set of queries. I would go with something like this /user/111/profile.

As far as performance it is probably better to have the back-end (maybe a database) get all the data together for a user profile and retrieve it with one request. In the scenario where you retrieve all the bits with separate requests you are stuck with the overhead of the extra HTTP requests.

Most of these decisions really depend on the requirements of the API. Also, this question/answer gives a very detailed explanation and should probably help you along as well.

Community
  • 1
  • 1
ophychius
  • 2,623
  • 2
  • 27
  • 49
  • Thank you for your answer. So as I understand it is normal practice to use REST as back-end for mobile app? But I need to thinking about reducing requests count by creation custom resources like profile? – Oleg Mishenkin Sep 01 '16 at 11:54
  • You don't necessarily do it just to reduce requests. It is also a clearer way to work. If you want to enable clients to get a userprofile, why would you make them put it together themselves from multiple requests, so it makes sense to have a userprofile readily available through your API. – ophychius Sep 01 '16 at 12:59