---
title: resource_search
full: true
_openapi:
  method: POST
  toc: []
  structuredData:
    headings: []
    contents:
      - content: >
          Searches for resources in public Datasets satisfying the search
          criteria.


          It returns a dictionary with 2 fields: `count` and `results`. The
          `count` field contains the total number of Resources found without the
          limit or query parameters having an effect. The `results` field is a
          list of dictized Resource objects.


          The 'query' parameter is a required field. It is a string of the form
          `{field}:{term}` or a list of strings, each of the same form. Within
          each string, `{field}` is a field or extra field on the Resource
          domain object.


          If `{field}` is `"hash"`, then an attempt is made to match the
          `{term}` as a *prefix* of the `Resource.hash` field.


          If `{field}` is an extra field, then an attempt is made to match
          against the extra fields stored against the Resource.


          Note: The search is limited to search against extra fields declared in
          the config setting `ckan.extra_resource_fields`.


          Note: Due to a Resource's extra fields being stored as a json blob,
          the match is made against the json string representation. As such,
          false positives may occur:


          If the search criteria is:


          ```

          query = "field1:term1"

          ```


          Then a json blob with the string representation of:


          ```json

          {"field1": "foo", "field2": "term1"}

          ```


          will match the search criteria! This is a known short-coming of this
          approach.


          All matches are made ignoring case; and apart from the `"hash"` field,
          a term matches if it is a substring of the field's value.


          Finally, when specifying more than one search criteria, the criteria
          are AND-ed together.


          The `order` parameter is used to control the ordering of the results.
          Currently only ordering one field is available, and in ascending order
          only.


          The context may contain a flag, *search_query*, which if True will
          make this action behave as if being used by the internal search api.
          ie - the results will not be dictized, and SearchErrors are thrown for
          bad search queries (rather than ValidationErrors).
---

{/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */}

Searches for resources in public Datasets satisfying the search criteria.

It returns a dictionary with 2 fields: `count` and `results`. The `count` field contains the total number of Resources found without the limit or query parameters having an effect. The `results` field is a list of dictized Resource objects.

The 'query' parameter is a required field. It is a string of the form `{field}:{term}` or a list of strings, each of the same form. Within each string, `{field}` is a field or extra field on the Resource domain object.

If `{field}` is `"hash"`, then an attempt is made to match the `{term}` as a *prefix* of the `Resource.hash` field.

If `{field}` is an extra field, then an attempt is made to match against the extra fields stored against the Resource.

Note: The search is limited to search against extra fields declared in the config setting `ckan.extra_resource_fields`.

Note: Due to a Resource's extra fields being stored as a json blob, the match is made against the json string representation. As such, false positives may occur:

If the search criteria is:

```
query = "field1:term1"
```

Then a json blob with the string representation of:

```json
{"field1": "foo", "field2": "term1"}
```

will match the search criteria! This is a known short-coming of this approach.

All matches are made ignoring case; and apart from the `"hash"` field, a term matches if it is a substring of the field's value.

Finally, when specifying more than one search criteria, the criteria are AND-ed together.

The `order` parameter is used to control the ordering of the results. Currently only ordering one field is available, and in ascending order only.

The context may contain a flag, *search_query*, which if True will make this action behave as if being used by the internal search api. ie - the results will not be dictized, and SearchErrors are thrown for bad search queries (rather than ValidationErrors).


<APIPage document={"./lib/openapi.yml"} operations={[{"path":"resource_search","method":"post"}]} />