2015-04-22 15 views
9

Próbuję zbudować spokojny interfejs API w stylu, używając springMVC.SpringMVC - styl wzorcowy adresu operatora wywołującego

Po skonfigurowaniu wzorca adresu URL dla springMVC DispatcherServlet, wydaje się, że mam do wyboru 2 i potrzebuję porady.

Wybór A:
config wzór jako: <url-pattern>*.action</url-pattern>
i wykorzystanie działania ścieżka jak @RequestMapping("/role/add.action")

Wybór B:
config wzór jako: <url-pattern>/api/*</url-pattern>
i wykorzystanie działania ścieżka jak @RequestMapping("/api/role/add")

Wolę używać stylu, który nie ma sufiksu, ale w takim przypadku potrzebuję dd ścieżkę podrzędną.

Ale nie jestem pewien, który jest bardziej odpowiedni do użycia w projekcie, który służy jako zaplecze do zapewnienia spokojnego API, z przeglądarką/IOS/Android jako klientem.


Nie może być wybór C, ale nie jestem pewien:

config wzór jako: <url-pattern>/*</url-pattern>
i wykorzystanie działania ścieżka jak @RequestMapping("/role/add")

W tym przypadku wbudowanej serwlet zostanie nadpisany, np. jsp nie będzie działał normalnie.
Ale nie mam żadnego jsp, a także, statyczne zasoby, takie jak html/js/css/image/document/music/video są umieszczane na innym porcie lub serwerze obsługiwanym przez nginx, żądanie do tomcat tylko świadczenie usługi ajax za pośrednictwem danych json.
Czy w takim przypadku właściwe jest użycie opcji C, czy ma ona pewne złe efekty uboczne?

+1

Polecam używanie Wiosna startowych, co eliminuje potrzebę każda taka specyfikacja. – chrylis

+0

@chrylis Czy możesz pomóc w wyjaśnieniu, jak wiosenny rozruch to naprawić? Ponieważ zgodnie ze specyfikacją serwletu, nie mogę znaleźć wzorca, który nie ma żadnego przyrostka ani ścieżki podrzędnej, a jednocześnie mógłby uniknąć zastąpienia wbudowanych serwletów. –

+0

Spring Boot zarządza dla Ciebie całym kontenerem, więc nie musisz w ogóle określać żadnych ścieżek. – chrylis

Odpowiedz

3

jeśli twoim celem jest spokojny api mój wybór jest drugi od zidentyfikowaniu zasobu w adresie URL; powiedzieć trzeba zarządzać zasobem rola powinna masz jakieś odwzorowanie jak te z nich:

@RequestMapping("/api/role" method = RequestMethod.POST) 

wstawić nową rolę (może być api to nie pozwala)

@RequestMapping("/api/role/{roleId}" method = RequestMethod.PUT) 

zaktualizować istniejącą rolę

@RequestMapping("/api/role/{roleId}" method = RequestMethod.DELETE) 

usunąć rolę

@RequestMapping("/api/role" method = RequestMethod.GET) 

do pobierania ról (możesz zaimplementować niektóre filtry za pomocą ciągu zapytania)

To samo dotyczy innych zasobów (Użytkownik, itp.) Schemat nazewnictwa jest taki sam.

I vould uniknąć wariant C, ponieważ myślę, że najlepiej mieć dedykowany mapowanie dla API jeśli App również wysyłać interfejs WWW, który nie korzysta z API

3

Polecam Wybór B dla usług RESTful, rozważ wykonanie operacji CRUD przy użyciu REST. I można mapować url-pattern jako,

config pattern as: <url-pattern>/api/*</url-pattern> 

więc wykonać dodać, wystarczy upewnić się, że pisać obiekt JSON ze strony i mieć url podobny /api/add

aw przypadku usuwania, możesz po prostu podążać tą samą drogą. Załóżmy, że usuniesz object z listy, używając jej identyfikatora.Można po prostu zrobić to na zewnątrz jak

/api/delete/${id}

i obsługiwać go jak,

@RequestMapping(value="/{id}", method=RequestMethod.GET) 
+0

Dobra sugestia, ale wiele api ma wiele parametrów, więc nadal potrzebuję wstawić parametr po '?' Lub w ciele http, jak sądzę. –

+0

Tak, zależy to również od interfejsu API. dlaczego nie używasz obiektów dla wielu parametrów. –

+0

Czasami używam obiektu, ale dotyczy to również tylko części API, np. Usługa wyszukiwania może mieć więcej parametrów z wielu modeli. –

Powiązane problemy