Блог

Главная - Вопросы по программированию - REST: одна и та же конечная точка для ресурса с разными условными параметрами

REST: одна и та же конечная точка для ресурса с разными условными параметрами

#java #spring-boot #rest

#java #весенняя загрузка #rest

Вопрос:

Давайте предположим, что у меня есть конечная точка, вызываемая

 /people

который, как следует из названия, возвращает набор пользователей. Вместо возврата «всех» пользователей запрашивающая сторона может добавить параметр запроса «q», который может иметь два возможных синтаксиса (скажем, S1 и S2).

  • S1 запустит определенную логику, которая полностью отличается от S2
  • S1 принимает набор параметров запроса {P1S1, P2S1, P3S1}
  • S2 принимает набор параметров запроса {P1S2, P2S2, P3S2}, который не имеет ничего общего с набором S1

У меня могла бы быть такая подпись:

 public Page<Person> people(@RequestParam String q, String p1s1, String p2s1, ..., String p2s2, String p3s2) {
 if (q contains S1 syntax)
   ...
 else (q contains S2 syntax)
   ... 
}

в зависимости от значения q я мог бы проверить последующие параметры и выполнить соответствующую логику поиска. Я сомневаюсь, что интерфейс в этом случае не был бы формально описан. Другими словами, глядя на интерфейс, неясно, какой параметр требуется, когда.

Есть ли правильный способ смоделировать / реализовать этот сценарий?

Комментарии:

1. Если два набора входных параметров также связаны с разным поведением запросов и разными результатами, тогда я мог бы предложить просто иметь две конечные точки.

2. как могут называться эти конечные точки? Оба должны быть «/ people», потому что они возвращают одно и то же точное представление одного и того же объекта. Я бы просто перенес неоднозначность интерфейса с параметров на имена конечных точек

3. Я не могу осмысленно ответить на ваш комментарий, не зная реальной конечной точки и параметров.

4. Ок, q = строка запроса, (смещение результатов размер страницы в случае S1), (выделенный, нечеткий, многоязычный в случае S2)

5. Первая проблема проектирования с точки зрения REST: вы уже считаете, что это /people вернет данные, относящиеся к конкретным пользователям, и, следовательно, будет иметь типизированный ресурс . Вторая проблема: вы рассматриваете конечную точку как вызов метода RPC вместо ресурса