Problem we need to fix

For now, retrieving lists of locations and content items is done either through the Location and Content services, or with the Search Service.

The Location and Content service offer limited ways to do that:

• by id or identifier
• relations or reverse relations
• children of a location

More complex lists (filtering, sorting), require the search service. The drawback is that it relies on the Search backend, very often Solr, by essence asynchronous. It can't be relied upon for a backoffice usage, as some items that were deleted could still be returned, and items recently created may not be indexed yet.

Solution

Add filtering methods to the API that use the database instead of the search index. Compared to the search service, they would not support Fulltext search, but would accept a Filter (criteria, sorting, offset and limit):
ContentService::filterContent(Filter $filter, array $languageSettings)LocationService::filterLocations(Filter $filter, array $languageSettings)

Open questions

Field value based filtering ?

Can we do field value based filtering ? The original discussions concluded that wouldn't be part of the first version as the database doesn't support it or has limited support.

DIfferenciate Content and Location filters ?

Do we need different objects, since some criteria won't apply to location or content ?