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:
[CODE=java]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();
}[/CODE]
... anstatt java.util.Date wäre natürlich LocalDate die bessere Option.
