title: Is that a good practice to provide a aggregation API in a Rest or a normal WebAPI Design?
body: <p>I have provide such REST API for getting base user info and user's space info.</p>
  
  <p><strong>/v1/users/{user_id}/profile</strong>, which will return such a JSON:</p>
  
  <p>```json
  {</p>
  
  <p>"id":123,
    "name":"foo",
    "sex":0,
    "email":"foo@gmail.com",
  }
  ```</p>
  
  <p><strong>/v1/users/{user_id}/space</strong> , which also return a JSON:</p>
  
  <p>```json
  {
    "sum_space":100,
    "used_space":20,
  }</p>
  
  <p>Now if a client (e.g. web page, a 3rd application) have a view which need to show part of user info(e.g "name", "sex") and part of user space info (e.g "sum_space") in a same time, Do I need to provide a new aggregation API such like <code>/v1/users/{user_id}</code>?</p>
  
  <p>And if I provide such a aggregation API, should it return all attributes of User and Space? if I did so, the return value will include some unused values, which will increase the bandwidth of network. But if this API just return what client need, what should I do if a new client requirement come(e.g just get a user's name and user's used_space)?</p>
  
  <p>If I don't provide any aggregation API, all the client must call N times for getting N kinds of resource. if there are a requirement for filter search(e.g getting user list which sum space > 100), the client could only do this serially.</p>
  
  <p>I am very confuse about those, is that any guideline to follow?</p>