2016-05-04 9 views
0

У меня есть приложение Джерси, которое было преобразовано в 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), но это нелегко адресовать случай использования по каждому пути.

Есть ли простой способ достичь этого?

ответ

0

Я зарегистрировал отчет об ошибке с весной (SPR-14481) касательно этого вопроса. В разговоре там, похоже, нет простого способа декларативно указать используемый тип содержимого по умолчанию.

0

«defaultContentTypeStrategy» позволяет предоставить собственную ContentNegotiationStrategy для использования. Он имеет доступ к полному запросу, поэтому вы можете принимать решения на основе пути, возможно, с помощью AntPathMatcher, чтобы легко поддерживать шаблоны.

+0

Похоже, что в то время как эта стратегия делает возможным *, это, конечно, не упрощает. Было бы сложно сообщить, что я хочу, чтобы у определенного контроллера/контроллера был определенный параметр по умолчанию. Мне нужно либо жестко закодировать соответствующие пути, либо написать кучу кода для поддержки этого использования. В любом случае поведение по умолчанию для контроллера (или метода) будет хорошо удалено из фактического контроллера/метода. Плюс AntPathMatcher не обязательно будет работать, если конкретный путь соответствует нескольким методам контроллера. –

+0

Продолжая предыдущий комментарий, также нет способа получить от предоставленного NativeWebRequest фактический метод контроллера/контроллера, который будет вызываться. –