Question

我正在构建一个非常以用户为中心的restful api。这意味着每个请求都以用户：api.test.com/rest/user/{user_id}开头。从这个/用户路径开始，可以获得关于用户的大量资源。作为一个例子

api.test.com/rest/user/{user_id}/case
api.test.com/rest/user/{user_id}/picture
api.test.com/rest/user/{user_id}/anSoOn

使用泽西我创建了一个用@Path（“user”）注释的类。现在我必须添加我的所有其余路径，这些路径以此类中的/user开头（在此示例中为picture，anSoOn）。这将极大地炸毁我的用户类，因为在所有资源上我也将提供所有原油操作。在球衣中有没有办法拆分子路径/user/{user_id}/case等等？

编辑：感谢Lutz Horn的回答。我想补充一些信息：

关于/case和/user的操作也应该是可行的。这会导致为@Path("/user")，@Path("/case")和@Path("/user/{userid}/case")创建课程。如果在这种情况下只能创建两个类，那将是很好的：@Path("/user"), @Path("/case")。但我想这是不可能的......

Answer 1

这是一个非常合理的问题......在为每个类定义非常大的根资源（包含许多“子资源”）之后，我也开发了很长的类...根源资源我的意思是@Path关于类定义的资源声明。

这是我刚刚测试过的，可能是更好地设计和组织（子）“资源”类的好“模式”。基本上，我们的想法是在更细粒度的级别创建一个根资源（每个类）（让我们称之为“子资源”），在您的情况下：

api.test.com.rest.user.Case.java类/rest/user/{user_id}/case，包含对此“子资源”执行所有CRUD操作的方法;
api.test.com.rest.user.Picture.java /rest/user/{user_id}/picture类，包含对此“子资源”执行所有CRUD操作的方法......

所以基本上你可以用每个资源的包来组织你的类（例如：api.test.com.rest.user.*包将包含资源“user”的每个“子资源”的类。）

在“子资源”类中，您将获得以下类型的构造：

@Path("/user/{user_id}/case")
public class Case { 

   @GET
   @Produces(MediaType.APPLICATION_JSON)
   public UserCase getUserCase(@PathParam("user_id") String userID) {
   ...
   }

   // all other CRUD operations on "user/user_id/case"

正如您所看到的，处理GET的“方法”没有@Path ...您只会对在“类”级别声明的@Path执行CRUD操作...这些操作也从那里开始user_id。

在某些情况下，您需要将这些类放在一起而不是“子资源”CRUD操作......但是这种设计应该允许更好地划分代码（与“大类”相比））。

HTH！

Answer 2

在课堂上使用@Path("/user/{user_id}/case")。

如何构建球衣路径以避免大班

2 个答案: