<html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body bgcolor="#FFFFFF" text="#000000"> Hi folks, as we move to offer more search functionality in our API, I am becoming a bit worried about our architecture in that respect. If I look at the search service we have written for the "link typeahead" feature, we see code that parses a query string in a format that is special to this exact API call, and converts it directly into a query on the postgres db. If we look at what the code does, it could be expressed like this: <code>searchTerms:= parseSpecialSyntax(queryString)</code> <code>return select * from work_items i where i.id matches(searchTearms) or i.title matches(searchTerms) or i.Description matches(searchTerms)</code> While the first line is specific to this particular API call, the second part can be reused in other queries. I have tried to express this separation in the WorkItemRepository.List() method by passing in a tree of operators that describes the query instead of a query string. I am quite open to discuss how we want to offer a search API on our object model to the request handlers, but I think that we need an internal search API layer that offers what we can search for in a structure way. Query parsing for special case queries (for example, parsing well known URLs) should not be part of this API, but done in a layer above. This way we can reuse a lot of checks (for example for sql injection) and the translation to the sql layer. I believe that we will write a bunch of special case queries that we will be able to map to a relatively simple set internal search API calls. /Thomas </body> </html>