Jak uzyskać dostęp do parametrów w metodzie RESTful POST

Twoja metoda @POST powinna przyjmować obiekt JSON zamiast ciągu znaków. Jersey używa JAXB do obsługi marshalingu i unmarshalingu obiektów JSON(zobacz dokumenty jersey po szczegóły ). Utwórz klasę podobną do:

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

Wtedy twoja metoda @POST wyglądałaby następująco:

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

Ta metoda spodziewa się otrzymać obiekt JSON jako ciało postu HTTP. JAX-RS przekazuje treść wiadomości HTTP jako niezapowiedziany parametr -- input w tym przypadku. Na rzeczywista wiadomość wyglądałaby mniej więcej tak:

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

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

Używanie JSON w ten sposób jest dość powszechne z oczywistych powodów. Jeśli jednak generujesz lub zużywasz je w czymś innym niż JavaScript, musisz uważać, aby poprawnie uciec od danych. W JAX-RS, można użyć MessageBodyReader i MessageBodyWriter do zaimplementowania tego. Uważam, że Jersey ma już implementacje dla wymaganych typów (np. Java primitives i JAXB klas), a także dla JSON. JAX-RS obsługuje wiele innych metod przekazywania danych. Nie wymagają one tworzenia nowej klasy, ponieważ dane są przekazywane za pomocą prostego przekazywania argumentów.

HTML <FORM>

Parametry będą opisywane za pomocą @ FormParam :

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

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

Treść jest URL zakodowany w tym przypadku.

Jeśli nie znasz nazw FormParam ' s, możesz wykonać następujące czynności:

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

Nagłówki HTTP

Możesz użyć adnotacji @HeaderParam jeśli chcesz przekazać parametry za pomocą nagłówków HTTP:

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

Oto jak wyglądałaby wiadomość HTTP. Zauważ, że ten POST nie ma ciało.

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

Nie używałbym tej metody do przekazywania uogólnionych parametrów. Jest to bardzo przydatne, jeśli chcesz uzyskać dostęp do wartości konkretnego nagłówka HTTP.

Parametry zapytań HTTP

Ta metoda jest używana głównie z http GETs, ale ma również zastosowanie do postów. Używa adnotacji @QueryParam.

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

Podobnie jak poprzednia technika, przekazywanie parametrów przez łańcuch zapytania nie wymaga treści wiadomości. Oto wiadomość HTTP:

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

Musisz być szczególnie ostrożny, aby poprawnie zakodować parametry zapytania Po stronie klienta. Używanie parametrów kwerendy może być problematyczne ze względu na ograniczenia długości adresów URL wymuszane przez niektóre proxy, a także problemy związane z ich kodowaniem.

Parametry ścieżki HTTP

Parametry ścieżki są podobne do parametrów zapytania, z tym wyjątkiem, że są osadzone w ścieżce zasobów HTTP. Metoda ta wydaje się być dziś za. Istnieją skutki w odniesieniu do buforowania HTTP, ponieważ ścieżka jest tym, co naprawdę definiuje zasób HTTP. Kod wygląda trochę inaczej niż pozostałe, ponieważ adnotacja @Path została zmodyfikowana i używa @PathParam :

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

Wiadomość jest podobna do parametru query version z tym wyjątkiem, że nazwy parametrów nie są nigdzie zawarte w wiadomości.

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

Ta metoda ma takie samo kodowanie jak zapytanie wersja parametru. segmenty ścieżek są kodowane inaczej więc tam też musisz być ostrożny.

Jak widzisz, każda metoda ma swoje plusy i minusy. O wyborze decydują zazwyczaj twoi klienci. Jeśli obsługujesz strony HTML oparte na FORM, użyj @FormParam. Jeśli Twoje klienty są oparte na JavaScript+HTML5, prawdopodobnie będziesz chciał użyć serializacji opartej na JAXB i obiektów JSON. MessageBodyReader/Writer implementacje powinny zadbać o niezbędne dla to jest jedna rzecz mniej, która może pójść źle. Jeśli twój Klient jest oparty na Javie, ale nie ma dobrego procesora XML (np. Android), prawdopodobnie użyłbym kodowania FORM, ponieważ treść jest łatwiejsza do wygenerowania i poprawnego kodowania niż adresy URL. Mam nadzieję, że ten wpis mini-wiki rzuci trochę światła na różne metody, które obsługuje JAX-RS.

Uwaga: w interesie pełnego ujawnienia, nie użyłem jeszcze tej funkcji Jersey. Majstrowaliśmy przy tym ponieważ wdrożyliśmy wiele aplikacji JAXB + JAX-RS i przenosimy się do przestrzeni klienta mobilnego. JSON jest o wiele lepiej dopasowany niż XML w rozwiązaniach opartych na HTML5 lub jQuery.