Next

I refactored the feed functionality out of the API request code and into Core\Boost\Feed abstract class and implemented Core\Boost\Feeds\Boost concrete class. In the review site the feed request response exactly matches the pre-refactored response (tested web only, need to capture a mobile request).

Example web request: /api/v2/boost/feed?rating=2&rotator=1&sync=1&limit=150&as_activities=0&from_timestamp

The functionality appears limited, oddities found so far...

• limit in request is not honoured
• rotator=1 is requested but not used anywhere
• sync=1 is requested but not used anywhere
• Iterator makes a request for X boosts, if Y of those boosts are invalid or can not be resolved the iterator will return X - Y boosts, requiring additional requests to cycle the iterator (which could return few or no results again)
• It is not implicit that boosts are always returned in ascending timestamp order
• It is not clear what a boost 'rating' is
• We ignore the offset requested from the iterator and instead override with the timestamp of the last boost in list with no explanation why we don't trust the iterator

added Sprint::10/09 - Pink Panther Status::InProgress scoped labels

assigned to @gthouret

changed title from Investigate Oddities in existing Boost Feed API code to Investigate Oddities and improve existing Boost Feed API functionality

changed the description