It had been in the back of my mind that using HTTP GET for searching in a project I was working on would lead to trouble and several hours of re-factoring later I am proved correct.

Background

The default way we do searching in the ServiceAPI is using HTTP GET, for example:

http://localhost/ServiceAPI/Record?pageSize=20&q=all&filter=extension:docx,xlsx&properties=RecordTitle&format=json

There are several advantages to use the GET verb but there is also a trap which is that IIS has limitations on the length of a URL.  Usually this is not a problem and the ServiceAPI has design features to help keep URLs concise (such as custom property sets) however I encountered a scenario where I could not avoid the IIS error resulting from an overlong URL.

The scenario

The scenario that caught me was needing the flexibility for the end user to specify as many properties in the properties query parameter as they desired and I did not want to use the 'all' property set as I did not want the cost of fetching every record property.  If the user chose too many properties their request would fail.

The solution

The solution is that the ServiceAPI allows you to POST the same request that you usually GET, you just have to post it to a different end point.  There are a couple of examples of this using an form post and AJAX in the documentation, here is an example using the .Net client.

TrimClient client = new TrimClient("http://localhost/ServiceAPI");
client.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials;


PostSearch request = new PostSearch();
request.TrimType = BaseObjectTypes.Record;
request.q = "all";
request.Properties = new PropertyList(PropertyIds.RecordTitle, PropertyIds.RecordNumber);

var response = client.ServiceClient.Send<RecordsResponse>("POST" , "Search", request);

foreach (Record rec in response.Results)
{
    Console.WriteLine(rec.Title);
}