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;
}
Ensuite, 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"}
En utilisant 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 un MessageBodyReader et MessageBodyWriter pour le 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 d' "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¶m2=world
Le contenu est encodé URL dans ce cas.
Les en-Têtes HTTP
Vous pouvez à l'aide de l' @HeaderParam d'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. 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.
Les Paramètres de la Requête HTTP
Cette méthode est principalement utilisée avec HTTP Obtient, mais il est tout aussi applicable à des Postes. Il utilise l' @QueryParam d'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¶m2=world HTTP/1.1
Content-Length: 0
Host: www.example.com
Vous ne devez être particulièrement prudent pour bien 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.
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 l' @Path d'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 de sorte que vous ne devez être prudent.
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 servez de l' FORM-en fonction des 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. L' 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 (jQuery) solutions.
