This problem is the same as any other model based parameter binding scenario whereby one of your params/properties is a list of some simple type (e.g. List<Guid>). The Sitecore ID class does seem to be treated as a "simple" type, similar to the Guid type in terms of param binding. This makes sense because an ID IS a Guid. This is an important point, because it shows that the ID class is not seen as a complex / custom type by the runtime (which would require custom binding logic).
As the comments mentioned:
- Formatting the query string as
?TemplateIds ={guid}&TemplateIds ={guid} does work. This is the standard approach when using model binding for list fields. One obvious drawback is that the query string may be longer and more verbose than you would like.
- Parameter binding also works, although there are simpler options such as...
- A manual approach:
[HttpGet]
[Route("sitecore/api/search")]
public IHttpActionResult Search(string? templateIds = null)
{
var filter = new MySearchFilter
{
TemplateIds = types.ToIds()
};
}
Where ToIds() is something like:
public static List<ID> ToIds(this string? value)
{
if (value != null)
{
string[] ids = value.Split(',', '|');
return ids
.Select(x => ID.TryParse(x, out ID id) ? id : ID.Null)
.Where(x => !ID.IsNullOrEmpty(x))
.ToList();
}
return new List<ID>();
}
This way the query string can be formatted as a comma separated string:
?TemplateIds={xxxx},{xxxx}
The benefit of the manual approach is having more control over which params can be accessed if the param model contains many fields, some of which may not be relevant or may be lacking an implementation. The manual approach is simple, flexible, and potentially more secure, but it can result in a good amount of code duplication if this pattern is implemented in many different areas.
