Should have mentioned that I knew about the various "Request Filters" that are in place. But you are making a huge assumption that is where people keep whether a testcase is automated or not. We use that field to describe the Type of testcase it is in relation to System, Performance, UI, or whatnot. It would be a waste of the field to just use it for "manual" or "automated".
So we have a custom field ("testcase_state") that we use for this.
In addition, there are some other fields we would like to search on rather than have the entire suite returned to us -- and none of them are those standard Request Filters.
Then this is compounded by the fact that the entire testcase record is returned to us -- we can't specify the information that we need. So lets take an example, a very simple testcase (no steps, no real informaton, just a title) returns 605 bytes. This is probably the smallest record possible (and many records are 2-3 or more times the size).
If I have 5000 testcases I am dealing with (we are) that means the json response has to return 3,025,000 bytes. I only need the information from a very small portion of that (specifically the ID and a few custom fields). But it has to download the entire thing.
And as I said before, this doesn't work as we get those testcases up in the 30k range (30k on simple testcases would return an over 18m json response).
Basically, this doesn't scale. We definitely need a way to either have the response return only certain fields (based on REST parameters I would guess) or give us access to more fields (such as custom ones) when using the Request Filter so that I can reduce the number of responses.
Of course, best of all would be both.