Я думаю, что есть тысячи правильных решений для этой проблемы (как я понял).
IMO, сервер API должен предоставлять максимально гибкую И читаемую услугу из возможных (легко понятную для обоих разработчики клиентов и новые разработчики на стороне сервера, которые присоединятся к команде), чтобы другие клиенты могли использовать его в будущем.
Подход 1027 * -restless очень гибок, все же строгий, и я принял его, хотя проект давно не поддерживается. Поскольку он не поддерживается, я бы не стал его использовать сейчас, однако я думаю, что реализованная там логика фильтрации c очень solid.
Параметры фильтрации, которые этот проект ожидает получить от клиента несколько громоздки, хотя охватывают большинство случаев, о которых я мог подумать.
Один объект фильтра выглядит следующим образом:
{"name": <fieldname>, "op": <operatorname>, "val": <argument>}
Где name может быть "first_name" "last_name" или любой другой атрибут объекта. op может быть '==', '! =', et c. и val - значение для фильтрации.
И объект фильтра полного запроса может выглядеть так:
{"or": [<filterobject>, {"and": [<filterobject>, ...]}, ...]}
Таким образом, запрос может выглядеть следующим образом:
GET /api/person?q={"filters":[{"or":[{"name":"age","op":"==","val":10},{"name":"age","op":"!=","val":20}]}]} HTTP/1.1
Я бы изучил их документацию по поисковому формату , чтобы получить asp идею, и если вы решите go для нее, я бы использовал реальный код, который извлекает фильтры (поскольку его с открытым исходным кодом и доступны в GitHub )