•
Enough IDs will be provided so that the front end should only have to make one set of follow-up requests for each feed item. This will keep feed items relatively light while reducing waterfall requests for all relevant information that will be displayed
•
The feed items will be specific to each entity, as they have different requirements (for example: documents have variants, groups have separate feed items for each item that is changed, etc.)
•
In cases where no other APIs are available, content will be inlined into the feed items. For example: there is no API for accessing previous profile information
•
One feed item may be provided from the API that will be used across several different UI feed items (for example: group content removal may be presented by the API as a group content update, same with all document updates+creates) as long as enough information is provided for the appropriate UI to be rendered
•
UI text is driven by the front-end