Aiuto su sessioni in Grizzly e JAX-WS

[fermat]

Hai messo "get" nel path, quindi non è proprio secondo la filosofia e le convenzioni REST.


No, non proprio. Se una API REST la si sviluppa "stateless" ... è meglio. In questo caso per stateless si intende che non si dovrebbe tenere sù una "sessione" lato server. In altre parole, tutto ciò che serve per interpretare e soddisfare una request, deve essere passato dal client, senza che ci debba essere già un qualche "stato" presente sul server.

ciao andbin!

per quanto riguarda il get, ho notato che se lo levo non mi funziona più.
ad esempio:

@Path("zona")
public class ZonaService {

    // @GET
    @Path("/zone/")
    @Produces(MediaType.APPLICATION_JSON)
    public ArrayList<Zona> getAll() {
        ZonaQueries query = new ZonaQueries();
        ArrayList<Zona> list = null;
        try {
            list = query.getAll();
        } catch (ClassNotFoundException | SQLException | MappableException ex) {
            throw new NotFoundException(new JsonError("Errore", ex.getMessage()));
        }
        return list;
    }
}

se lo apro con un browser, mi da pagina bianca.
se lo decommento, invece, vedo il json a video.

per quanto riguarda il resto, ho perfettamente compreso.
ma se ad esempio volessi dare la possibilità di scaricare in excel i risultati di cui sopra, dovrei duplicare questo metodo?
oppure che alternativa avrei??

[andbin]

per quanto riguarda il get, ho notato che se lo levo non mi funziona più.

Non l'annotazione @GET (quella ovviamente serve) ma il "/get" che avevi messo nel path.

REST si basa su convenzioni e su una filosofia ben precisa. Anche e soprattutto riguardo gli URL da usare. L'obiettivo principale è quello di far sì che gli URL rappresentino delle "risorse".

Es.

GET http://blabla.com/api/books (=lista tutti i libri)
POST http://blabla.com/api/books (=inserisce nuovo libro)
GET http://blabla.com/api/books/1234 (=dettaglio del libro Id 1234)
PUT http://blabla.com/api/books/1234 (=aggiorna il libro Id 1234)
DELETE http://blabla.com/api/books/1234 (=elimina il libro Id 1234)

come vedi non c'è un "get" nel path. Il GET è la "azione" ed è il metodo HTTP.

ma se ad esempio volessi dare la possibilità di scaricare in excel i risultati di cui sopra, dovrei duplicare questo metodo?

Innanzitutto bisogna vedere chi è il "client". Un browser? Una applicazione "desktop"?
Comunque se a parità di url vuoi fornire rappresentazioni differenti (es. un excel o un pdf piuttosto che un JSON) una opzione è lavorare con i media type. Se è il client che fornisce Accept:application/json tu gli dai un JSON, se fornisce Accept:application/pdf gli dai un pdf, ecc... Ma qui ripeto, dipende anche da chi è il client, da cui deriva la possibilità di controllare gli header o no.

In alternativa sfruttare delle estensioni per rappresentazioni particolari.

http://blabla.com/api/books/1234 (JSON standard)
http://blabla.com/api/books/1234.pdf (un pdf)

Non è il massimo ma si fa anche ...

[fermat]

Non l'annotazione @GET (quella ovviamente serve) ma il "/get" che avevi messo nel path.

REST si basa su convenzioni e su una filosofia ben precisa. Anche e soprattutto riguardo gli URL da usare. L'obiettivo principale è quello di far sì che gli URL rappresentino delle "risorse".

Es.

GET http://blabla.com/api/books (=lista tutti i libri)
POST http://blabla.com/api/books (=inserisce nuovo libro)
GET http://blabla.com/api/books/1234 (=dettaglio del libro Id 1234)
PUT http://blabla.com/api/books/1234 (=aggiorna il libro Id 1234)
DELETE http://blabla.com/api/books/1234 (=elimina il libro Id 1234)

come vedi non c'è un "get" nel path. Il GET è la "azione" ed è il metodo HTTP.

ah ok ok.
no vabbè, negli altri path il /get non c'è.
quella è una prova volante per vedere se funzionava il download del file.

Innanzitutto bisogna vedere chi è il "client". Un browser? Una applicazione "desktop"?
Comunque se a parità di url vuoi fornire rappresentazioni differenti (es. un excel o un pdf piuttosto che un JSON) una opzione è lavorare con i media type. Se è il client che fornisce Accept:application/json tu gli dai un JSON, se fornisce Accept:application/pdf gli dai un pdf, ecc... Ma qui ripeto, dipende anche da chi è il client, da cui deriva la possibilità di controllare gli header o no.

In alternativa sfruttare delle estensioni per rappresentazioni particolari.

http://blabla.com/api/books/1234 (JSON standard)
http://blabla.com/api/books/1234.pdf (un pdf)

Non è il massimo ma si fa anche ...

allora, in generale, il client è un browser che interroga i service tramite ajax per prelevare i dati, e metterli su uno altro db.
nel caso specifico dell'excel, sarebbe sempre un browser, ma ancora devo capire se userei ajax o no.
cmq sempre un browser!