Comment accéder aux paramètres dans une bonne méthode POST

Votre @POST méthode doit être l'acceptation d'un objet JSON au lieu d'une chaîne. Jersey utilise JAXB à l'appui de regroupement et désordonnancement objets JSON (voir le maillot docs pour plus de détails). Créer une classe comme:

@XmlRootElement
public class MyJaxBean {
    @XmlElement public String param1;
    @XmlElement public String param2;
}

Alors votre @POST méthode serait la suivante:

@POST @Consumes("application/json")
@Path("/create")
public void create(final MyJaxBean input) {
    System.out.println("param1 = " + input.param1);
    System.out.println("param2 = " + input.param2);
}

Cette méthode s'attend à recevoir un objet JSON dans le corps du POST HTTP. JAX-RS qui transmet le contenu du corps du message HTTP comme un annotées paramètre -- input dans ce cas. Le message réel ressemblerait à quelque chose comme:

POST /create HTTP/1.1
Content-Type: application/json
Content-Length: 35
Host: www.example.com

{"param1":"hello","param2":"world"}

À l'aide de JSON de cette façon est assez commun pour des raisons évidentes. Toutefois, si vous êtes à la produire ou de consommer dans autre chose que JavaScript, alors vous ne devez être prudent afin d'échapper correctement les données. Dans JAX-RS, vous devez utiliser une MessageBodyReader et MessageBodyWriter à mettre en œuvre. Je crois que Jersey a déjà des implémentations pour les types (par exemple, Java primitives et JAXB enveloppé classes) ainsi que JSON. JAX-RS prend en charge un certain nombre d'autres méthodes pour transmettre des données. Ceux-ci ne nécessitent pas la création d'une nouvelle classe, puisque les données sont transmises à l'aide de simple argument de passage.

---

HTML <FORM>

Les paramètres devaient être annotées à l'aide d' @FormParam:

@POST
@Path("/create")
public void create(@FormParam("param1") String param1,
                   @FormParam("param2") String param2) {
    ...
}

Le navigateur va coder le formulaire à l'aide de "application/x-www-form-urlencoded". JAX-RS runtime prendre soin de décoder le corps et de le transmettre à la méthode. Voici ce que vous devriez voir sur le fil:

POST /create HTTP/1.1
Host: www.example.com
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Content-Length: 25

param1=hello&param2=world

Le contenu est encodée URL dans ce cas.

Si vous ne connaissez pas les noms des FormParam vous pouvez effectuer les opérations suivantes:

@POST @Consumes("application/x-www-form-urlencoded")
@Path("/create")
public void create(final MultivaluedMap<String, String> formParams) {
    ...
}

---

En-Têtes HTTP

Vous pouvez à l'aide de la @HeaderParam annotation si vous voulez passer des paramètres via les en-têtes HTTP:

@POST
@Path("/create")
public void create(@HeaderParam("param1") String param1,
                   @HeaderParam("param2") String param2) {
    ...
}

Voici ce que le message HTTP ressemblerait. Notez que ce POST n'est pas un corps.

POST /create HTTP/1.1
Content-Length: 0
Host: www.example.com
param1: hello
param2: world

Je ne voudrais pas utiliser cette méthode généralisée passage de paramètres. Il est vraiment pratique si vous avez besoin d'accéder à la valeur d'un en-tête HTTP cependant.

---

HTTP Paramètres de Requête

Cette méthode est principalement utilisée avec HTTP Obtient, mais il est tout aussi applicable à des Postes. Il utilise le @QueryParam annotation.

@POST
@Path("/create")
public void create(@QueryParam("param1") String param1,
                   @QueryParam("param2") String param2) {
    ...
}

Comme la technique précédente, passant des paramètres via la chaîne de requête ne nécessite pas un corps de message. Voici le message HTTP:

POST /create?param1=hello&param2=world HTTP/1.1
Content-Length: 0
Host: www.example.com

Vous devez faire particulièrement attention à bien les encoder les paramètres de la requête sur le côté client. En utilisant les paramètres de la requête peut être problématique en raison de la longueur des URL des restrictions appliquées par certains proxies ainsi que les problèmes liés à l'encodage eux.

---

HTTP Chemin Paramètres

Chemin paramètres sont identiques aux paramètres de la requête, sauf qu'ils sont incorporés dans le HTTP chemin d'accès aux ressources. Cette méthode semble être en faveur d'aujourd'hui. Il y a des répercussions à l'égard de la mise en cache HTTP depuis le chemin est vraiment ce qui définit la ressource HTTP. Le code est un peu différent que les autres depuis le @Path annotation est modifié et il utilise @PathParam:

@POST
@Path("/create/{param1}/{param2}")
public void create(@PathParam("param1") String param1,
                   @PathParam("param2") String param2) {
    ...
}

Le message est similaire à la requête de paramètre version sauf que les noms des paramètres ne sont pas inclus dans le message.

POST /create/hello/world HTTP/1.1
Content-Length: 0
Host: www.example.com

Cette méthode de partage le même encodage des maux que le paramètre de requête version. Les segments de tracé sont encodés différemment donc, vous ne devez être prudent, il y a l'.

---

Comme vous pouvez le voir, il ya des avantages et des inconvénients de chaque méthode. Le choix est généralement choisi par vos clients. Si vous êtes au service des FORMà base de pages HTML, puis utilisez @FormParam. Si vos clients sont JavaScript+HTML5 sur, alors vous voudrez probablement utiliser JAXB à base de sérialisation et d'objets JSON. Le MessageBodyReader/Writer implémentations devraient prendre soin de la nécessité de s'échapper pour vous c'est de moins en moins de chose qui peut aller mal. Si votre client est basé sur Java, mais ne pas avoir un bon processeur XML (par exemple, Android), alors je serais probablement utiliser FORM encodage depuis un contenu corps est plus facile à générer et à encoder correctement que les Url sont. J'espère que ce mini-wiki entrée jette une certaine lumière sur les différentes méthodes que JAX-RS prend en charge.

Remarque: dans l'intérêt de la divulgation complète, je n'ai pas réellement utilisé cette fonctionnalité de Jersey encore. Nous avons été bricoler avec elle car nous avons un certain nombre de JAXB+JAX-RS applications déployées et se déplacent vers le mobile espace client. JSON est un bien meilleur ajustement que le XML sur HTML5 et jQuery-fondé des solutions.