目前我們的電影服務只提供了對電影信息的訪問服務，現在我們要再增加兩項級服務，分別用來訪問導演和演員信息。加上原先的電信信息服務，我們把 URI 統一放到 /ms/rest/service/ 的子路徑下。最先想到的方法就是為這三個 URI 分別寫 JAX-RS 服務：
@Singleton
@Path("service/movie")
public class MovieService {
// 此處省略若干行
}
@Singleton
@Path("service/director")
public class DirectorService {
// 此處省略若干行
}
@Singleton
@Path("service/director")
public class ActorService {
// 此處省略若干行
}
這種寫法的缺點就是讓三個本來有點關系（父級 URI 相同）的服務被放到了毫不相干的三個類里面，不一個個類地查看注解難以看出這點關系。為此，JAX-RS 提供了動態資源綁定的功能，讓我們能夠對這種情況做一些整理。
首先，我們引入一個服務定位器來處理集中管理這三個子級服務：
@Singleton
@Path("service")
public class ServiceLocator {
@Inject
private MovieService movieService;
@Inject
private DirectorService directorService;
@Inject
private ActorService actorService;
private Map<String, Object> serviceMap;
@PostConstruct
private initServiceMap() {
serviceMap = new HashMap<>();
serviceMap.put("movie", movieService);
serviceMap.put("director", directorService);
serviceMap.put("actor", actorService);
}
@Path("{name}")
public Object locateService(@PathParam("name") String name) {
Object service = serviceMap.get(name);
if (service == null) {
throw new WebApplicationException(Status.SERVICE_UNAVAILABLE);
}
return service;
}
}
該類中的 locateService 方法根據服務的名稱返回相應的服務實例，注意該方法只有一個 @Path 注解，因為它并不清楚請求的具體內容；返回對象的類型為 Object，表明動態資源定位不要求服務類實現相同的接口，只需要它們的方法帶有相應的 JAX-RS 注解，就能夠被 JAX-RS 自動發現和處理（專業術語稱為 introspect，內省），以 MovieService 為例：
@Singleton
public class MovieService {
@GET
@Path("{id}")
@Produces(MediaType.APPLICATION_JSON)
public Movie find(@PathParam("id") int id) {
Movie movie = movieDao.get(id);
if (movie != null) {
return movie;
} else {
throw new WebApplicationException(Status.NOT_FOUND);
}
}
// 此處省略若干行
}
這樣，每個請求實際上都由兩個類先后處理。例如，處理請求 GET /ms/rest/service/movie/1 的時候，先由 ServiceLocator 返回相配的服務實例 movieService，然后再由該實例的 find 方法返回結果。比起最開始那三個簡單的類，雖然多了一層調用，但換來了更加清晰的結構。
動態資源定位是一個非常靈活強大的功能，用好的話，完全可以把 URI 層次整理成一個類似于文件目錄結構的抽象文件系統。