2009-06-05 12 views
7

Diciamo che abbiamo un'applicazione web Grails che espone diverse risorse.Applicazione grails RESTful: DRY up up UrlMapping

  • tag
  • URL
  • utenti

L'applicazione ha un'interfaccia web classica cui gli utenti interagiscono con e un po 'di amministrazione. Vogliamo esporre le risorse dall'applicazione ai client tramite un'API RESTful e non vogliamo che quella parte di app ingombra i controller e il codice che abbiamo già. Quindi abbiamo trovato il seguente:

Se l'interfaccia web offre host/app_path/url/[list|show|create], vogliamo che l'API REST sia a /host/app_path/rest/url.

Così ci siamo ritrovati con il seguente file urlMappings:

Il problema è che questo non è esattamente la cosa più DRY qui. Diventa peggio quando aggiungiamo più risorse come i tag. Avrebbero traducono ancora altri tre blocchi di codice molto simile ...

Le funzioni non CRUD saranno cose come cercare con criteri specifici e tali ...

abbiamo provato generare le chiusure di mappatura con un ciclo , ma senza successo. Siamo completamente sulla strada sbagliata qui?

risposta

7

mi sento di raccomandare il seguente mappatura:

"/rest/url/$id?"(resource:"urlRest") 

Di seguito è il metodo HTTP per la mappatura un'azione che questo avrebbe creato per l'urlRestController:

GET   show 
PUT   update 
POST  save 
DELETE  delete 

vedo il motivo per cui si potrebbe desiderare di mappare/Rest/url POST per salvare e/rest/url/id PUT per aggiornare, ma questo va contro il significato di quei verbi. Un PUT dovrebbe essere l'unico modo per aggiungere un nuovo url e POST l'unico modo per aggiornare un URL. Farlo nel modo in cui hai lavorato funzionerebbe e potrebbe essere il modo migliore se il tuo vincolo è mantenere intatto il codice del tuo attuale controllore. Tuttavia, la mia ipotesi è che il controller potrebbe già essere codificato per gestire i mapping predefiniti correttamente (aggiorna/cancella emette un errore se nessun ID, mostra i reindirizzamenti da elencare se nessun ID, ecc.).

+1

Ah, la cosa PUT/POST: D – kungfoo