Понимание того, как работает Spring MVC в @RequestMapping POST

Question

У меня есть простой контроллер, который выглядит следующим образом: -

@Controller 
@RequestMapping(value = "/groups") 
public class GroupsController { 
    // mapping #1 
    @RequestMapping(method = RequestMethod.GET) 
    public String main(@ModelAttribute GroupForm groupForm, Model model) { 
     ... 
    } 

    // mapping #2 
    @RequestMapping(value = "/{id}", method = RequestMethod.GET) 
    public String changeGroup(@PathVariable Long id, @ModelAttribute GroupForm groupForm, Model model) { 
     ... 
    } 

    // mapping #3 
    @RequestMapping(method = RequestMethod.POST) 
    public String save(@Valid @ModelAttribute GroupForm groupForm, BindingResult bindingResult, Model model) { 
     ... 
    } 
} 

В основном, эта страница имеет следующие функциональные возможности: -

• пользователь посещает главную страницу (/groups GET).
• Пользователь создает новую группу (/groups POST) или выбирает определенную группу (/groups/1 GET).
• Пользователь редактирует существующую группу (/groups/1 POST).

Я понимаю, как оба GET-запроса отображаются здесь. Определяется сопоставление # 2, иначе (/groups/1 GET) приведет к исключению «Без сопоставления».

То, что я пытаюсь понять, вот почему отображение # 3 обрабатывает оба (/groups POST) и (/groups/1 POST)? Имеет смысл, что он должен обрабатывать (/groups POST) здесь, поскольку сопоставление запросов соответствует URI. Почему (/groups/1 POST) не вызывает исключение «Нет сопоставления найденных» здесь? На самом деле, почти похоже, что любой POST с URI, начинающийся с/groups (например: /groups/bla/1 POST), также будет обрабатываться путем сопоставления # 3.

Может кто-нибудь дать мне это ясное объяснение? Большое спасибо.

РАЗЪЯСНЕНИЕ

Я понимаю, тот факт, что я могу использовать более подходящие методы (например, GET, POST, PUT или DELETE) ... или я могу создать еще одно отображение запроса для обработки /groups/{id} POST.

Однако то, что я хочу, чтобы действительно знать ...

.... "Почему отображение # 3 ручки /groups/1 POST тоже?"

«Ближайшие совпадения» рассуждения кажутся недействительными, потому что если я удалю сопоставление # 2, то я думаю, что отображение # 1 будет обрабатывать /groups/1 GET, но это не так, и оно вызывает «Нет сопоставления найдено исключение.

Я просто немного здесь.

Answer 1

Это сложно, я думаю, что лучше прочитать код.

Весной 3.0 Волшебство выполнено по методу public Method resolveHandlerMethod(HttpServletRequest request) внутреннего класса ServletHandlerMethodResolver из org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.

Экземпляр этого класса существует для каждого класса контроллера запросов и имеет поле handlerMethods, которое содержит список всех методов запроса.

Но позвольте мне подвести итог, как я понимаю

• пружина сначала проверяет, если по крайней мере один метод обработчика соответствует (это может содержать ложные негативы)
• Затем он создает карту всех действительно подходящие методов обработчиков
• Затем он сортирует карту по запросу пути: RequestSpecificMappingInfoComparator
• и занимает первое один

Сортировка работает следующим образом: RequestSpecificMappingInfoComparator сначала сравнивает путь с помощью AntPathMatcher, если в соответствии с этим два метода равны, тогда другие показатели (например, количество параметров, количество заголовков и т. Д.) Учитываются с помощью в отношении запроса.

Answer 2

Весна пытается найти карту, которая соответствует ближайшим.
Следовательно, в вашем случае любого запроса POST единственной картой, найденной для типа запроса, является Mapping # 3. Ни из сопоставления 1, ни для сопоставления 2 не соответствует типу вашего запроса и, следовательно, игнорируется. Может быть, вы можете попробовать удалить карту # 3 и увидеть, что Spring выдает ошибку времени выполнения, так как не находит соответствия!

Answer 3

добавить @PathVariable параметру Long ид в отображении # 2

Answer 4

Я хотел бы добавить отображение PUT для/групп/{ID}. Я думаю, что POST будет работать, но не строго корректно с точки зрения HTTP.

добавление @RequestMapping ("/ {id}", POST) должно покрывать его?