POST /entity/_text_search

_search needs a type and a field path. This needs neither: it takes words, and a map of the types to look in.

Params

The value of an entity_types key is read by the parser the vendor content type selects, the same split filters on POST /entity/<type>/_search is under:

No value satisfies both: [] under api3_hash is 400, and a group under api3_array is 400.

Sample requests

One type, no filter:

ARR = {"Content-Type": "application/vnd+shotgun.api3_array+json"}
r = c.post("/entity/_text_search", headers=ARR,
           json={"text": "<word>", "entity_types": {"Shot": []}, "page": {"size": 1}})

The row is flattened, and is not what _search returns:

{
  "data": [
    {
      "id": 862,
      "type": "Shot",
      "attributes": { "name": "<shot code>", "links": ["", ""], "status": "ip" },
      "links": { "self": "/api/v1/entity/shots/862" }
    }
  ]
}

Three types at once, where the value of each key is that type's own filter:

r = c.post("/entity/_text_search", headers=ARR,
           json={"text": "<word>",
                 "entity_types": {"Shot": [["project", "is", {"type": "Project", "id": 70}]],
                                  "Asset": [], "Version": []},
                 "page": {"size": 3}})

The same map under api3_hash, where every value is a group and a condition may be one:

HSH = {"Content-Type": "application/vnd+shotgun.api3_hash+json"}
P = ["project", "is", {"type": "Project", "id": 70}]
r = c.post("/entity/_text_search", headers=HSH,
           json={"text": "<word>",
                 "entity_types": {
                     "Shot": {"logical_operator": "and",
                              "conditions": [P, {"logical_operator": "or",
                                                 "conditions": [["code", "is", "sh010"],
                                                                ["code", "is", "sh020"]]}]},
                     "Asset": {"logical_operator": "and", "conditions": []}},
                 "page": {"size": 3}})

200: the two named Shots, and the Assets the words match, in the row shape above. Sending the array form under this Content-Type answers 400 with the value echoed back:

{"errors": [{"status": 400, "code": 103,
             "title": "Query is not an Hash: [[\"project\", \"is\", {\"type\" => \"Project\", \"id\" => 70}]]",
             "source": {}}]}

Response codes

Edge cases

• There is no fields parameter. Every row is name, links and status, whatever the type, so a client that needs more re-reads the row by its links.self.
• attributes.links is a two-element array of strings, the linked row's type and its name, and it is ["", ""] for a type that links to nothing. It is not an entity reference and cannot be followed.
• entity_types maps a type to a filter, so one call can be scoped differently per type. That is the only place in the API where a filter is keyed by the type it applies to.
• The shape is checked per key, so one call cannot mix the two forms. The key holding the value the Content-Type does not name decides the 400, and no type answers rows.
• One bad key fails the whole call: a field the type lacks, an operator its data type lacks, or a key no entity type is named by is 400 for every type in the map, not a type dropped from the answer.
• A group under api3_hash may hold another group, to at least three levels, and or returns the union of its branches. The array form takes basic condition arrays alone, and two of them are the and of both.
• The response has no links, so paging is page.number and there is nothing that says a further page exists. Ask until data is empty.
• text is matched case-insensitively against the row's name and against the name of the row under attributes.links. It is not matched against description.