У меня есть приложение Джерси, которое было преобразовано в Spring MVC. Одной функциональностью, с которой я не вижу способа прямого подключения, является способность каждого пути указывать предпочтительный тип носителя, если он не указан. В Джерси я мог бы указать свойство «qs» для типа носителя, и он использовал бы это, чтобы определить, какой тип ответа отправить, если ни один не был указан (или если в заголовке Accept указано несколько параметров, я считаю, что это значение было умножено по показателям качества).Можете ли вы указать предпочтительный тип носителя по умолчанию для одного пути в Spring MVC?
@Produces("application/json")
@GET
@Path("/some/path")
public Response preferredResponse() {
//Implementation goes here
}
@Produces({"application/schema+json;qs=0.9"})
@GET
@Path("/some/path")
public Response preferredResponse() {
//Implementation goes here
}
В этом примере, если я запрос GET против «/ какой/путь» без заголовка Accept, он возвращает ответ приложения/JSON.
Я не вижу в этом простой способ сделать это в Spring MVC, особенно если я хочу ограничить использование по умолчанию только одной конечной точкой (в приложении есть другие конечные точки, которые должны иметь другой предпочтительный по умолчанию). Я вижу, что есть способ глобально установить тип контента по умолчанию (по методу «defaultContentType» и «defaultContentTypeStrategy» в ContentNegotiationConfigurer), но это нелегко адресовать случай использования по каждому пути.
Есть ли простой способ достичь этого?
Похоже, что в то время как эта стратегия делает возможным *, это, конечно, не упрощает. Было бы сложно сообщить, что я хочу, чтобы у определенного контроллера/контроллера был определенный параметр по умолчанию. Мне нужно либо жестко закодировать соответствующие пути, либо написать кучу кода для поддержки этого использования. В любом случае поведение по умолчанию для контроллера (или метода) будет хорошо удалено из фактического контроллера/метода. Плюс AntPathMatcher не обязательно будет работать, если конкретный путь соответствует нескольким методам контроллера. –
Продолжая предыдущий комментарий, также нет способа получить от предоставленного NativeWebRequest фактический метод контроллера/контроллера, который будет вызываться. –