Devo usare il tipo di data in JAX-RS @PathParam?

Sembra una cattiva idea. Per prima cosa, la funzione di costruzione Date su cui si fare affidamento è stata deprecata da Java 1.1 a favore di DateFormat.parseDate (), proprio perché non è chiaro come le stringhe debbano essere analizzate in date, poiché le regole sono diverse per località diverse.

La mia raccomandazione sarebbe quella di attenersi a un formato specifico, preferibilmente compreso a livello internazionale yyyy-MM-dd, e usare un DateFormat per analizzare la data da una stringa all'interno del tuo servizio, il che rende chiaro come utilizzare il servizio web, e ti permette di seguire qualsiasi convenzione standard per la restituzione dei messaggi di errore è per i tuoi servizi web quando qualcosa va storto.

Sto utilizzando una classe personalizzata DateParam :

@GET
@Path("/{name}/{date}")
public String getMessages(@PathParam("name") String name, @PathParam("date") DateParam date)
  Date date = date.getDate();

La classe è definita come:

public class DateParam {
  private final Date date;

  public DateParam(String dateStr) throws WebApplicationException {
    if (isEmpty(dateStr)) {
      this.date = null;
      return;
    }
    final DateFormat dateFormat = new SimpleDateFormat("yyyy-MM-dd");
    try {
      this.date = dateFormat.parse(dateStr);
    } catch (ParseException e) {
      throw new WebApplicationException(Response.status(Status.BAD_REQUEST)
        .entity("Couldn't parse date string: " + e.getMessage())
        .build());
    }
  }

  public Date getDate() {
    return date;
  }
}

Se il parametro è vuoto, si otterrà una data null. È possibile estendere DateParam da un campo finale statico pubblico per valori di data non definiti. Ciò renderebbe più chiaro il test per i parametri della data non definiti.

Uno svantaggio è che per ogni DateParam viene creata una nuova istanza di SimpleDateFormat. Tuttavia, dal momento che SimpleDateFormat non è thread-safe, non possiamo riutilizzarlo facilmente.

Chi userà il tuo servizio? Si prenderanno la briga di cercare le specifiche della classe Date e capire quale tipo di stringhe analizzeranno? Non lo farei, anche se essendo un programmatore Java vorrei sapere dove guardare; -)

Penso che dovresti prima dire ai tuoi utenti come saranno gli URI, ad es.

.../your-resource-name/yyyy-MM-dd

e quindi cerca un modo per farti aiutare da Jersey nell'analisi di qualsiasi formato di data tu abbia scelto. Ciò potrebbe significare utilizzare un tipo di parametro Date e magari specificare un'espressione regolare nell'annotazione @Path , come

@Path(/{name}/{date: [0-9][0-9][0-9][0-9]-[0-1][0-9]-[0-3][0-9]/)

o usando qualche altra classe in grado di analizzare una data nel tuo formato. Come gestire gli URI che non corrispondono alle specifiche fornite agli utenti è un'altra cosa che dovresti decidere come gestire indipendentemente da quanto sopra (restituisci una risorsa predefinita? Restituisci un errore 404?).