@Jdlrobson this should probably be one of the first tasks completed just to get the response updated as discussed by the Services team on T150039

@Fjalapeno an empty REST endpoint has already been added as part of T145662.
Real content will be added as part of T145553 so I've added T145553 as a blocking task.

@Fjalapeno is it possible for someone in your team / Android team to work on this in parallel with me doing T145572 ?
Im not too familiar with how this stuff works and I think if we did that we'd wrap up this work quicker.

cc @bearND

In T150186#2819213, @Jdlrobson wrote:

@Fjalapeno is it possible for someone in your team / Android team to work on this in parallel with me doing T145572 ?
Im not too familiar with how this stuff works and I think if we did that we'd wrap up this work quicker.

cc @bearND

Actually most likely the one working on this would be me, it should be done in RESTBase side.

@Pchelolo This would be great. So, you'd add the $merge property to the trending-edits repo? Would you need to do anything in RB as well? In other words how generic is the $merge property feature in RB. Is it tied to just the aggregated feed endpoint or enabled for any endpoint?

I think the reason why @Jdlrobson pinged the iOS team and me is that he would like one of us to drive how to output format looks like based on the requirements. We've already started a discussion about this in T150039, so I added some of my thoughts there.

@bearND $merge feature is very generic and can be used for any endpoint. Also, do we want to store the results in RESTBase to get a historic view of trending articles?

Yes, I believe we would like to store historic results of trending articles in RB eventually. I'm not sure if we need it now.

@bearND The design of the public endpoint path depends on this: whether we want to include the /{yyyy}/{mm}/{dd} in the path? Or even include an /{hh} portion for more fine-grained history?

Please keep the discussion about historic data inside T146999 so we don't lose it!