Quote Originariamente inviata da andbin Visualizza il messaggio
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!