Support JSON:API filters

What you're describing sounds like JSON:API Cross Bundles (https://www.drupal.org/project/jsonapi_cross_bundles)

If you still need to do it yourself, have you looked at how this is done in \Drupal\jsonapi\Controller\EntityResource::getCollectionQuery? The $params array comes from getJsonApiParams.

May be this is worth a Trait 🤔

HI suresh7787,

Did you able to filter on custom resources? Can you share how did you did it?

Thanks.

Discussion with @mglaman on Slack:

ptmkenny
8 hours ago
Is it possible to use regular JSON:API filters (like /jsonapi/my-resource&filter[group-name][group][conjunction]=OR&filter[filter-name][condition][path]=n... on a JSON:API Resource created with the JSON:API Resources module? It seems they are not supported out of the box, but is it possible to get filter support working, or do I have to add my own parameters to the resource to use instead of filters?

mglaman
7 hours ago
I thought it’d work, as we expand filters like normal

mglaman
5 hours ago
I guess I’m wrong, we don’t provide methods for this

mglaman
5 hours ago
it was added in jsonapi_search_api but these helper methods should be applied in jsonapi_resources https://git.drupalcode.org/project/jsonapi_search_api/-/blob/8.x-1.x/src/Resource/IndexResource.php?ref_type=heads#L159-176

mglaman
5 hours ago
https://git.drupalcode.org/project/jsonapi_search_api/-/blob/8.x-1.x/src/Resource/IndexResource.php?ref_type=heads#L190-197

mglaman
5 hours ago
https://git.drupalcode.org/project/jsonapi_search_api/-/blob/8.x-1.x/src/Resource/IndexResource.php?ref_type=heads#L208-212

I started on an MR for this.

To get filters to work, you need to add the following code to the process() method of your custom JSON:API resource:

    $cacheability = new CacheableMetadata();
    if ($request->query->has(Filter::KEY_NAME)) {
      $this->applyFiltersToQuery($request, $entity_query, $cacheability);
    }

    if ($request->query->has(Sort::KEY_NAME)) {
      $this->applySortingToQuery($request, $entity_query, $cacheability);
    }

    $data = $this->loadResourceObjectDataFromEntityQuery($entity_query, $cacheability);

However, the filters don't currently work because I don't understand how to get the resource type (see the comment in the MR code).

Filtering support is available. It works for me, but your mileage may vary.

An important note for filtering: the order of _jsonapi_resource_types in mymodule.routing.yml is important.

    _jsonapi_resource_types:
      ['node--base_for_entity_query', 'other_entity--bundle_type']

The first entity type listed must be the base for the entity query; if you put them in a random order, filters like entity_reference_field.referenced_entity_field will fail.

Hello,

is this fixed?

@sarbazx No, it's not fixed. If it was fixed, the status would be "Fixed", not "Needs work".

I wrote the MR and it works for me. But it doesn't have any tests (which probably need to be created for it to be merged), and no one else has reported using it successfully, so I don't know how well it works for other use cases. For my own site, it's working great.

With claude code, I made the following changes to the MR:

  src/Resource/EntityQueryResourceBase.php (+124/-8)
  - New imports: EntityFieldManagerInterface, ModuleHandlerInterface, TemporaryQueryGuard, FieldResolver, ResourceType.
  - Three new private properties + setters: setFieldResolver(), setFieldManager(), setModuleHandler().
  - applyFiltersToQuery() rewritten:
    - Early-return when Filter::KEY_NAME isn't on the request.
    - Resource type chosen by matching $query->getEntityTypeId() (replaces reset($route_resource_types) — no more silent
  dependence on routing order; throws a cacheable 400 with a specific message if no match).
    - Filter::createFromQueryParameter() now called with the injected $this->fieldResolver instead of
  \Drupal::service('jsonapi.field_resolver').
    - TemporaryQueryGuard::applyAccessControls() restored after the user filter is applied — closes the
  filter-as-information-oracle hole from commit f2841e8.
    - Catch narrowed to \UnexpectedValueException | \InvalidArgumentException; CacheableBadRequestHttpException propagates
   unwrapped to preserve original cacheability/message.
    - Docblock updated: real @throws CacheableBadRequestHttpException instead of the fictional @throws PluginException.
  - New private helper resolveFilterResourceType() does the entity-type-based lookup.
  - applySortingToQuery() untouched (sort fixes deferred to a follow-up).

  src/Unstable/DependencyInjection/JsonapiResourceClassResolver.php (+3)
  - In the EntityQueryResourceBase branch, wires jsonapi.field_resolver, entity_field.manager, module_handler via the new
  setters.

  tests/modules/jsonapi_resources_test/src/Resource/FeaturedNodes.php (+2)
  - Calls $this->applyFiltersToQuery($request, $query, $cacheability) so the canonical example demonstrates filter
  support.

  tests/src/Functional/JsonapiResourceTest.php (+55)
  - New testFilterOnFeaturedNodes(): creates 4 promoted + 1 non-promoted node, asserts (a) filter[title][value]=Bravo
  returns exactly the matching promoted node, (b) filtering for the non-promoted node's title returns zero results —
  confirming filter cannot override the resource's hard-coded promote=1 condition.

I have tested this locally against my React app.

With regard to the MR, I'm not sure if the new setter-injected dependencies are permissible or not:

• \Drupal\jsonapi\Context\FieldResolver
• \Drupal\Core\Entity\EntityFieldManagerInterface
• \Drupal\Core\Extension\ModuleHandlerInterface

Other than that, I think this is ready for review, so I am removing the "Draft" status from the MR.

Thanks ptmkenny! I'll get this reviewed and committed tomorrow

thank you, merged! I'll release soon

Thank you for fixing and committing, and thank you for the help getting this started in the first place!