JAX-RS Mehrere Parameter in Query

[internet]

Hallo zusammen,

ich bin gerade dabei meinen ersten Webservice zu erstellen, und habe hier eine Frage, was die Parameter anbelangt.
Ich möchte gerne die Möglichkeit haben, dass man Objekte nach "Erstelldatum" filtern kann.

Stripe macht das ganz gut wie ich finde. Hier gibt es folgende Parameter, die verwendet werden können:


Nun ist meine Frage, wie das im Code für JAX-RS aussehen muss.

Muss ich dafür tatsächlich für jeden Parameter einen "QueryParameter" erstellen im Methodenkopf angeben?

    @GET
    @Path("/")
    @Consumes(MediaType.APPLICATION_JSON)
    @Produces(MediaType.APPLICATION_JSON)
    public Response findAllCustomers(@QueryParam("created") String created,
                                    @QueryParam("created.gte") String created.gte,
                                    @QueryParam("created.lt") String created.lt) {

Ist das der richtige Weg oder löst man das besser?

2) Es handelt sich ja um ein Datum. Passt hier der Datentyp (String) überhaupt ?
Ich denke mal der Client muss das Datum dann im Datumformat ISO 8601 liefern, oder?

3) Habt ihr gute Beispiel Referenzen, die eine Jax RS API entwickeln haben, bei denen man den Code ansehen kann?

Danke

 

[Oneixee5]

Seit wann können Variablennamen einen . enthalten?

 

[mihe7]

Nun ist meine Frage, wie das im Code für JAX-RS aussehen muss.

Was heißt müssen... mit Hilfe der QueryParam-Annotation kannst Du einen bestimmten Query-Parameter auf einen Methodenparameter abbilden. Du kannst aber auch den UriInfo-Context injecten und auf alle Query-Parameter zugreifen:

@GET
    @Path("/")
    @Consumes(MediaType.APPLICATION_JSON)
    @Produces(MediaType.APPLICATION_JSON)
    public Response findAllCustomers(@Context UriInfo uriInfo) {
        MultivaluedMap<String, String> params = uriInfo.getQueryParameters();
        // ...
    }

 

[Oneixee5]

Es macht meiner Meinung nach keinen Sinn @GET und @Consumes(MediaType.APPLICATION_JSON) zu kombinieren. Wenn man mal überlegt wie eine URL für einen GET-Request aufgebaut ist und sich diese dann mit einen JSON-Dokument als Parameter vorstellt ...
Hier sollte erst mal nachgedacht werden, was man überhaupt erreichen will und ob für GET-Requests über JSON-Dokumente als Parameter benötigt werde.
Man muss einen Endpunkt auch nicht findAllCustomers nennen, wenn man die Rückgabemenge einschränken will. Dann sind es nämlich nicht ALLE (findAll...)
Ich würde vermutlich für jeden GET-Fall einen eigenen Endpunkt anlegen. So sind diese sauber getrennt, man hat sprechende Endpunkt-Bezeichner, der Code bleibt kurz und übersichtlich und lässt sich verständlich dokumentieren.
Zum Datum: oben in deinem Screenshot steht "Unix timestamp" das ist einfach nur ein Long-Wert (kein String) und die sinnvollste Art ein Datum zu übertragen. Wenn es unbedingt ein Datum in irgend einem String-Format sein muss, dann würde ich etwas in der Art machen:

public class DateParameter implements Serializable {
    public static DateParameter valueOf(String dateString) {
        try {
            date = CRAZY_FORMAT.parse(dateString);
        } catch(Exception e) {
            ...
        }
    }

    private Date date;
    // Constructor, Getters, Setters
    // public constructor that accepts a String
}

@GET ...
public Response<MyDTO> getByData(@QueryParam("date") DateParameter dateParam) {
    final Date date = dateParam.getDate();
}

... anstatt java.util.Date wäre natürlich LocalDate die bessere Option.