Explication détaillée de la méthode de routage de Spring basée sur les paramètres URL

Préface

Cet article présente principalement le contenu pertinent sur le routage de ressort basé sur les paramètres d'URL. Il est partagé pour votre valeur de référence et d'apprentissage. Jetons un coup d'œil à l'introduction détaillée ci-dessous.

Découvrir les problèmes

Récemment, j'ai trouvé un problème lors de l'écriture d'interfaces, c'est-à-dire que les parties de chemin des URL des deux interfaces de repos sont les mêmes, et elles se distinguent selon la requête passant dans différents paramètres.

Par exemple, l'interface de téléchargement normale de S3 est:

 Put / {backetname} / {objectName}

L'interface de téléchargement en morceaux est:

 Put / {backetname} / {objectName}? PartNumber = {PartNumber} & uploadID = {uploadID}

Le PartNumber et le UploadID sont une interface, et les deux paramètres ne sont pas transmis sont une autre interface. Alors, comment définir l'itinéraire au printemps?

Généralement, nous définissons les routes @RequestMapping(value = "/xx", method = RequestMethod.GET) . Ensuite, dans la signature de la méthode, les paramètres peuvent être injectés via @RequestParam.

Cependant, il n'est pas possible de mettre en œuvre directement la distinction en injectant différents paramètres, tels que:

 @ Réponsebody @ requestmapping (value = "/ xx", méthode = requestMethod.get) public String get1 () {return "get1";} @ réponsebody @ requestmapping (value = "/ xx", méthode = requestMethod.get) public string get2 (@requestparam name) {return "get2" + name;}

Cela rapportera une erreur:

 Java.lang.ILLEGALSTATEException: cartographie ambiguë. Impossible de mapper 'DemoController_v01' Méthode publique java.lang.string com.nd.sdp.ndds.controller.v01.democontroller.get1 () à {[/ démo / xx], méthodes = [get]}: il y a déjà 'Democontroller_v01' beeb

Solution

Cela signifie que vous vous êtes inscrit à plusieurs reprises, donc @RequestParam ne peut pas être utilisé comme base de routage.

@RequestParam

Utilisé pour traiter le type de contenu: contenu encodé pour l'application / x-www-form-urlencoced. (Dans le protocole HTTP, si le type de contenu n'est pas spécifié, le paramètre passé par défaut est le type d'application / x-www-forme-urlencodé)

RequestParam peut accepter les propriétés de types simples ou de types d'objets.

L'essence consiste à utiliser la conversion du mécanisme de conversion de Spring pour configurer la carte des paramètres de valeur de clé dans request.getParameter () pour la convertir en objet ou champ de réception de paramètre.

@RequestMapping est une annotation de routage. En plus du champ de valeur couramment utilisé pour définir l'URL, il fournit également un paramètre Params, qui peut spécifier comment correspondre aux paramètres de la requête dans l'URL. Plusieurs méthodes de configuration:

• myParam = myvalue correspond au paramètre myparam et est égal à l'URL de MyValue
• myParam! = MyValue correspond au paramètre MyParam et n'est pas égal à l'URL de MyValue
• Myparam correspond à l'URL avec le paramètre MyParam
• ! Myparam correspond à l'URL sans paramètre MyParam

Cela vous permet de spécifier les itinéraires de manière très flexible.

De plus, @ReQuestMapping fournit également le paramètre des en-têtes, qui nous permet de rouler en fonction de la situation d'en-tête!

Résumer

Ce qui précède est l'intégralité du contenu de cet article. J'espère que le contenu de cet article a une certaine valeur de référence pour l'étude ou le travail de chacun. Si vous avez des questions, vous pouvez laisser un message pour communiquer. Merci pour votre soutien à wulin.com.