Должны ли параметры пути в выражении jax-rs @Path быть разделены косой чертой?

Question

Я проверяю некоторый код в микросервисе пружинной загрузки JAX-RS, над которым я начинаю работать. Я увидел следующее (измененное):

@POST
@Path("{foo: ([^/]+?)?}{bar: (/[^/]+?)?}")
public Response doit(
        @PathParam("foo") String foo,
        @PathParam("bar") String bar,
        @RequestBody UpdateRequest updateRequest, @Context HttpHeaders httpHeaders);

Это значение @Path выглядит странно. Вместо того, чтобы иметь явные маркеры "/" в строке, он пытается сделать это через регулярное выражение. Я предполагаю, что это может работать, потому что это существующий код, но действительно ли это целесообразно? Есть ли причина, по которой это было бы необходимо?

Полагаю, похожий сомнительный пример будет таким:

@Path("foo{bar: (/[^/]+?)?}")

Есть ли причина, по которой это лучше, чем проще:

@Path("foo/{bar}")

Answer 1

Если вы только что использовали

@Path("foo/{bar}")

затем вызов /foo приведет к 404, потому что / является статическим и потребует запроса /foo/. Но когда он находится в регулярном выражении bar, это делает его необязательным. Итак, пример

@Path("foo{bar: (/[^/]+?)?}")

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

@Path("customers{id: (/[^/]+?)?}")

При этом у нас будет метод ресурса, который может обрабатывать как доступ к ресурсу коллекции , так и к одному ресурсу. В отличие от двух отдельных методов ресурсов, по одному для каждого случая. Например

@GET
@Path("customers{id: (/[^/]+?)?}")
public Response get(@PathParam("id") String id) {
    if (id == null) {
        return collection customers collection
    } else {
        fetch custom by id and return customer.
    }
}

Это единственное реальное преимущество, которое я вижу в этой ситуации. Вероятно, потребуется больше контекста, возможно, некоторые документирующие комментарии автора относительно того, что они пытались достичь. В целом, хотя, IMO код выглядит излишне сложным.

Answer 2

Спецификация JAX-RS , в частности, раздел «Шаблоны URI» в главе «Ресурсы», содержит ответ:

Параметры шаблона могут дополнительно указывать регулярное выражение, используемое для сопоставления их значений. Значение по умолчанию соответствует любому тексту и заканчивается в конце сегмента пути, но для изменения этого поведения могут использоваться другие значения, например ::

@Path("widgets/{path:.+}")
public class Widget {
  ...
}

В приведенном выше примере класс ресурса Widget будет сопоставляться для любого запроса, путь которого начинается с widgets и содержит хотя бы еще один сегмент пути; значением параметра path будет путь запроса, следующий за widgets. Например. учитывая путь запроса widgets/small/a, значение пути будет small/a.

Итак, если вы не предоставите пользовательское регулярное выражение, граница по умолчанию будет /.

Следовательно, это сложное регулярное выражение не нужно. @Path("{foo}/{bar}" хорошо.

Технически, это не совсем то же самое; регулярное выражение заставляет {bar} включать ведущие /. Стоит ли сложность регулярных выражений, которые требуют дополнительного визуального анализа? Не по моему мнению.