2009-06-05 11 views
7

Załóżmy, że mamy aplikację internetową grails prezentującą kilka zasobów.Aplikacja RESTful grails: DRY up up UrlMapping

  • tagi
  • adresy URL
  • użytkowników

Aplikacja posiada klasyczny interfejs WWW których użytkownicy korzystają z pewnego i administracji. Chcemy udostępnić zasoby z aplikacji klientom za pośrednictwem RESTful API i nie chcemy, aby ta część aplikacji zaśmiecała kontrolery i kod, który już mamy. Wyszukaliśmy następujące:

Jeśli interfejs WWW oferuje host/app_path/url/[list|show|create], chcemy, aby interfejs API REST był pod adresem /host/app_path/rest/url.

więc skończyło się z poniższym pliku UrlMappings:

Problem polega na tym, że nie jest to dokładnie najbardziej DRY rzeczą tutaj. Jest coraz gorzej, gdy dodajemy więcej zasobów, takich jak tagi. Będą tłumaczyć jeszcze innego trzech bloków o bardzo podobnym kodzie ...

Funkcje non-crud będą rzeczy jak wyszukiwanie konkretnych kryteriów i takie ...

Próbowaliśmy generując zamknięć odwzorowania z pętli , ale bez powodzenia. Czy jesteśmy tutaj zupełnie na niewłaściwym torze?

Odpowiedz

7

Polecam następujące odwzorowanie:

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

Poniżej jest metoda HTTP do mapowania działania, które spowodowałoby to dla urlRestController:

GET   show 
PUT   update 
POST  save 
DELETE  delete 

widzę dlaczego warto map/rest/url POST, aby zapisać i/rest/url/id PUT, aby zaktualizować, ale to jest sprzeczne ze znaczeniem tych czasowników. PUT to jedyny sposób na dodanie nowego adresu URL i POST jedyny sposób na aktualizację adresu URL. Zrobienie tego w taki sposób, w jaki się ułożyłeś, będzie działało i może być najlepszym sposobem, jeśli twoim ograniczeniem jest utrzymanie twojego obecnego kodu kontrolera nietkniętego. Jednak domyślam się, że kontroler może już być zakodowany, aby obsłużyć domyślne odwzorowania w porządku (aktualizacja/usuwanie daje błąd, jeśli nie ma identyfikatora, wyświetla przekierowania do listy, jeśli nie ma identyfikatora, itp.).

+1

Ahh, rzecz PUT/POST: D – kungfoo