我想知道具有更多经验和更复杂项目的人们如何与REST Communication中的这种“丑陋”相处.想象以下问题：

对于我们的REST基础结构中的一个特定资源,我们将需要大量的功能,就我而言,大约有50个功能会导致不同的查询和不同的响应.我试图考虑一个有意义的资源树,并将它们分配给将执行“工作”的方法.之后,服务器资源类如下所示：

@Path("/thisResource")    
public class SomeResource {

    @GET/POST/PUT/DELETE
    @Path("meaningfulPath")
    public Response resourceFunction1 ( ...lots of Params) {

        ... logic ....

    }

//
// lots of functions ...
//

    @GET/POST/PUT/DELETE
    @Path("meaningfulPath")
    public Response resourceFunctionN ( ...lots of Params) {

    ... logic ....
    }
}

为了构造我的客户端将调用的url,我做了一个小功能来防止Typos并更好地使用Constants

所以我的客户看起来像这样：

public class Client() {
    public returnType function1 () {
        client.resource = ResourceClass.build(Constants.Resouce, "meaningfulPath");
        ...
        return response.getEntity(returnType);
    }

}

现在困扰我的问题是如何更好地链接客户端功能和服务器功能？

这两个代码块之间的唯一连接是将由客户端调用并由服务器映射的URL,即使该URL是在其他位置生成的,也会引起很多混乱.

当我的一位同事需要使用此代码时,他很难确定50个客户端功能中的哪个导致了服务器功能.而且很难确定代码中是否有过时的函数,等等.我想你们大多数人都比我更了解不洁代码的问题.

您如何处理？您将如何保持此代码的清洁,可维护和精巧？

解决方法:

通常,这将通过EJB或类似技术解决.

或至少通过“实际” Web服务,它将至少提供WSDL和架构(with kind of mapping to Java interfaces, or “ports”).

但是REST通信的类型和结构非常松散.

我现在唯一想到的是：定义一个项目(称为“定义”),该项目将被客户端和服务器引用(因此已知).在这个项目中,您可以定义一个包含大量公共静态最终String的类,例如：

public static final String SOME_METHOD_NAME = "/someMethodName";
public static final String SOME_OTHER_METHOD_NAME = "/someOtherMethodName";

注意：注释可以很好地引用静态最终String(在这种情况下,编译器将其视为常量).因此,请使用“常量”来注释您的@Path,例如：

@Path(Definitions.SOME_METHOD_NAME)

客户端相同：

ResourceClass.build(Constants.Resouce, Definitions.SOME_METHOD_NAME);