Investigate Oddities and improve existing Boost Feed API functionality
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... (Checkbox Indicates Resolved)
-
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